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LETTER FROM THE SERIES EDITOR 


D ear Reader, 


First off | would like to thank the author of this book, М г. Ernest Pazera, for writing it. N ow the 
pressure is off me to cover 150 Game Programming once and for all - thanks Ernest! 


If you've picked up this book then you must have an interest in creating Isometric games. You have come 

to the right place. Isometric game programming is not the trivial task many 3D programmers think it is— 
in fact, Isometric rendering methods are not trivial, nor are they obvious. M oreover, the optimizations are 
very subtle. То date, no author has ever tried to write a book on the subject, since not only is the material 
complex, but it is in many cases a bit secret. 


Luckily for us, М г. Pazera has put down in these pages an unbelievable amount of information on every 
single topic of Isometric graphics and game programming. As | read the text | caught myself thinking, 
“So that’s how they do it!” more than once. 


T he bottom line is, if you want to learn Isometric game programming then you need this book— it's 
the only book that will fill the order. | happen to know that Ernest is obsessed with ISO game program- 
ming, and that both his attention to detail and his high standards of perfection are illustrated in this work. 


NEW аа 


Andre | aM othe 
March 2001 


INTRODUCTION 


INTRODUCTION 


T hank you for buying my book. | really appreciate it. 


Isometric games have been with us since the golden age of arcade machines, with games like Zaxxon and 
Q-Bat. T hey are still with us today— witness games like N ox and Age of К ings— and they аге as popular as 
ever. Yet there has never been a book on making isometric games. T hat is the void | am seeking to fill with 
| sometric б ame Programming with D iretX . 


T his Introduction will give you an overview of both the book itself and an introduction to the chapter 
structure contained herein. O ver the course of this book you will go from isometric programming novice 
to expert. О kay, maybe novice to intermediate. You cant quite get to expert in just a single book! 


[чаты 1N THIS BOOK? 


T his book, as you are no doubt aware, is a book about programming games— how to do so, specifically— 
and it emphasizes use of the isometric view. T his means that the program examples are mainly concerned 
with the graphical aspect of game programming. 


Contained herein is also quite a bit of information on the algorithms behind tile based games. Isometric 
games tend to be tile based. If you wanted to make overhead view tile based games, the same algorithms 
apply. 

W hy did | write this book, you ask? Because isometric game programming, and isometric algorithms, have 
been largely ignored by other game programming books. Sure, you can find plenty of books on how to 
program 3D games, and there are plenty of books on 2D games, but none of the in-between stuff, like 
isometric games. 


You will find the program examples (and there are a ton of them) that go along with the text on the CD 
in the back of the book; you will find instructions on how to load and run those examples in Appendix A. 
It is a good idea to turn to that appendix first, even before you start reading. T hat way, when the first men- 
tion of an example is made, you'll be ready to go. 


Ано SHOULD READ THIS BooK? 


You are a programmer who has a reasonable amount of skill in С/С++ (you dont have to be an expert— 
| made my code as easy to follow as possible). You must also be interested in making isometric games. You 
very likely play strategy games (either real time or turn-based), computer role playing games, or puzzle 
games (all of these genres make use of the isometric view quite heavily). 


N aturally, your goal is to make the greatest game of all time, and become filthy rich and buy a Corvette. 
Yeah, that's my goal too— it hasnt happened quite yet, but I'm patient. As with all things in life, we must 
walk before we can run, and before we can walk, we must crawl. 
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| wont tell you that immediately after reading this book you'll be able to go and make a wonderful game 
with the isometric view that will sell millions of copies. | will tell you, however, that this book will help 
you build a foundation of knowledge and algorithms that will make you a more valuable programmer. 


How THIS KOOK 15 ORGANIZED 


T he four parts contained in this book— and the topics they cover— are as follows: 


= Part I:T he Basics. Introduces the world of tile based isometric game programming and discusses topics 
common to all isometric games. 

= Part 11: Isometric Fundamentals. D elves into different ways of adding realism to isometric tile based games. 

= Part 111: Isometric M ethodology. Explores user interaction with isometric games and sheds light on more 
rendering topics. 

» Part IV: Advanced Topics. Introduces a final ingredient, artificial intelligence, and fits it together with what 
youve learned previously. 

= Part V: Appendices. Shows you how to load the example files into your compiler, and offers resaources for 
learning more about isometric game programming. 


CHAPTER STRUCTURE 


T he chapters are similar in structure, though the topics vary widely. Each chapter contains all or most of 
the following elements: 


= Overview. Each chapter starts with a brief overview, in which | give a brief rundown of the topics that will 
be discussed in that chapter, as well as a breakdown the chapter's topic headings. 

» Terminology. W hen а new concept is introduced and alot of new terms are thrown at you, there is a termi- 
nology section early in the chapter. T his does not apply to all the chapters, and many of the chapters in Part 
0 do not have them. 

= How-to Information. M ost of the content of each chapter contains information on how to accomplish the 
tasks that are covered in that chapter. U sually, a lot of code accompanies the text, and most of the time one 
or more sample programs are supplied for you to load, run, and modify to more fully explore the concepts 
put forth. 

= Libraries and Classes. Some chapters have code libraries that | have written to help you with the tasks you 
perform in that chapter. T hese libraries or classes simplify some otherwise complicated coding topics. After a 
library is used in one chapter, most of the rest of the chapters will use it also. 

= Empowering the U ser. Some chapters have a small section called “Empowering the U ser.’ T his little section 
has some tips on how to not alienate your users and keep them playing your games. M ost of the information 
is common sense, but many games and game devdopers have failed for the simple reason that they dont give 
the player enough control over his or her game experience. Perhaps an alternative name for the "Empowering 
the U ser" section would be “H ow to N ot T ick off the U ser” 

= Summary. Т he final part of the chapter consists of the summary. | review the topics we've discussed, and | 
often list things you should remember. T he summary brings a sense of dosure to the chapter. 
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CONVENTIONS USED 1N THIS KOOK 


NOTE 


Notes provide additional information about a 
feature, or extend an idea about how to do 
something. 


CAUTION 


Cautions warn you about potential 
problems and tell you what not to do. 


WIHATIS ON THE CDF 


T heCD that accompanies this book doesn't autorun and doesnt have a setup program. It just has a num- 
ber of folders for you to browse through. 


= DirectX. [п this folder, you'll find everything you need to install the DirectX 8.0 SDK. 

= Source. Т he Source directory contains a folder for each chapter that has a programming example. E ach folder 
is named ChapterX , where X is the chapter in question. 
Within each ChapterX folder are subfolders for each of the sample programs in the book. T hese contain the 
source code, the resources (such as bitmaps), and a precompiled executable. 
Keep in mind that when you copy files from a CD to a hard drive, they are often marked as read-only, so you 
need to right-click on them and unset that flag before modifying them. 

a Extras. T his folder contains, well, extras. M ost of them are in zip files, so you'll need W inZip (which you can 
download for free at www.winzip.com) to extract them. Some of the extras are written by me but most are 
contributions from others. 
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AND WERE OF Faun 


(Psst... T his is the summary.) 


All right. You've turned to Appendix A and learned how to load a project, right? N o?W ell go ahead and 
do so. T hat's about all you'll need to get started. T his first part of the book goes a little fast, from zero to 
DirectX in less than 200 pages. | hope youre ready! 


Engage, М г. Paris! 


THE BASICS 
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heW indows platform, no matter what you think of it, is the most viable platform on which 

to program for the home computer market. It has its weaknesses, yes, but you gotta love the 
market share! T hink of it: you can write programs that will run on Windows 95, 98, NT, 2000, 
Millennium, CE, and the X Box, and it only takes a modest amount of work to convert them. 


T his chapter is a bare-bones introduction to W IN 32 programming. If you've already got a solid footing 
fed free to skip it, but be sure to look at IsoH ex1 1.cpp, located on the CD-ROM . IsoH ех1 1.срр is my 
basic W IN 32 shell program; all future programs will be based on this foundation. 


If youre still here I'll try to be as brief while remaining complete and understandable. l'm not one for 
spouting a bunch of theory— | prefer practical applications. | will assume that you have a solid base in C 
and at least a familiarity with C++. І will make use of classes a bit later (but | swear unto you by all that 
is holy that there will be no M FC). Before you start pulling at your hair and shouting incoherently, | assure 
you | wont get too wacky. | wont force class hierarchies and virtual functions on you— just a few little 
utility classes to make our jobs a bit easier. 


N o matter what your personal feelings about theW indows O S, the fact that it is truly easy to use— its 
main selling point— is undeniable T his is a double-edged sword, of course. Because so much work went 
into making the O S easy to use, it is proportionally more difficult to program for. D O S, which was very 
hard to use, was easy to program for. So it goes. 


Luckily, there is only a small amount of W indows-specific stuff that you absolutely have to know in order 
to program for W indows (and thee was much rgoidng). T his chapter is here to get you up to speed on those 
things. T he programs we'll be doing wont be very complicated or functional, but they will provide a good 
base on which to get flying! 


CONCEPTUAL OVERVIEW OF 
DliNDODIS PROGRAMS 


W indows (including 95, 98, NT, and 2000) is a multitasking, multithreaded operating system. You've 
heard that line before, I’m sure. М ultitasking means that the computer can run more than one program at а 
time. Т he multithreaded part means that more than one thread (short for “thread of execution") can exist 
within a program. Each program has at least one thread in it. 

But, if you have just a single processor, doing more than one thing at a time is impossible, right? 


Technically that's correct, but you can make it sem like two or more things are happening simultaneously 
by dividing time between the different programs and threads within programs. 
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With aa fast-enough processor, the computer сап do some of one thing and some of another thing, 
switching back and forth between the two, and you, as a human being, cannot tell whether the tasks are 
being done simultaneously or not. N eat, huh? 


For instance, say you had two applications, Walk.exe and ChewG um.exe. If you ran both of these, Walk.exe 
would operate for a millisecond or so, and then the computer would switch to ChewG um.exe for a mil- 
lisecond, and then it would switch again, repeating until the applications end, as illustrated in Figure 1.1. 


Figure 1.1 


Switch to another application 


и НХ 


СНЕМ/ 
GUM.EXE 


Executes for a time slice Executes for a time slice 


‘Se ee 


Switch to another application 


The computer walking 
and chewing gum at 
the same time 


We human beings arent set up with the proper hardware 
to perceive the passing of milliseconds, so to us, it 
appears that the computer is indeed walking and NOTE 


chewing gum at the same time. 
І use the term milliseconds in this 


You could also have a program called example. In reality, the amount of time 
WalkA ndC hewG um.exe, and it would create one an application executes a given applica- 
thread that walks and another that chews gum. T he tion before switching to another one 
computer again would switch between the two depends on a number of things and is 
threads, and the same effect is achieved within a sin- most likely a unit of time other than 
gle program. a millisecond. My use of millisecond is 


my attempt to make the example 


: . seem more concrete.A more accurate 
time in the computer. As you add more and more DOMUS T 


applications and threads within those applications, 
more of the computer's time is taken up. At some 


T he apparently simultaneous effect is based on idle 
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point, depending on your processor (how many you have, how fast they are), you reach a threshold where 
the simultaneous appearance is gone, and you start to notice some lag in the applications. So how does this 
concern us as game programmers? 


Game programs are more demanding on the operating system and the hardware then any other type of 
program. Sloppy design and/ or sloppy programming cause the game program to reach the nonsimultane 
ous threshold all on its own, without any other applications running, T his is a bad thing. 


N one of the programs that you will write in this book will be multithreaded (it becomes confusing and 
gives me a headache). Also, none of them will be as optimized as they could be (the code is instruction- 
al— optimized code is by its nature rather cryptic, so it would defeat our purpose). 


T hat's quite enough about multithreading and multitasking, L е5 dive in, shall we? 


OF HUNDS AND HINSTANCES 


М uch of what we do іп W indows involves handles— most notably, window handles (нимо). So what are 
these handles all about, anyway? 


Н andles are pointers to pointers— sort of. T hey area preO OP (object-oriented programming) method of 
keeping track of data in a completely dynamic operating system (namely, Windows). At any moment, an 
applications code can be moved from regular memory into virtual memory (that is, saved to disk in a tem- 
porary swap file). A handle ensures that no matter where something is, you can still talk to it by passing 
the handle into a function. Keeping track otherwise would be a nightmare! 


Just treat handles as ordinary variables; you dont really care all that much about their implementation. 
Trust the operating system to keep track of windows and other things that use handles. 


T he three main types of handles that you will be using are HINSTANCE, нимо, and plain old vanilla-flavored 
HANDLE, Which you will use to access disk files. 


= HINSTANCE isahandleto the current instance of an application. (Yes, | know it's a circular defini- 
tion, but | got it right out of M SDN.) Windows internally manages all running applications, and 
HINSTANCE is just a way to keep track of which application owns which windows and which 
resources. 

= НИМО is а handle {о a window. It allows us to set the size, shape, and a variety of other aspects 
about a window. T he operating system manages these windows and determines which are visible the 
order in which to draw them, and the manner in which input (such as keystrokes and mouse move- 
ments) is directed. 

= HANDLE is what you will use to access files; I'll get to it in Chapter 8. A normal old HANDLE is 
pretty generic. 


T here will be more handle types in the next chapter, so consider yourself warned. T hey are used quite a bit 
with graphical objects in W indows. 
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LIFE IN AN EVENT-DRIVEN 


OPERATING SYstTem 


W indows is actually a very simple mechanism. W henever something happens— a mouse moves, a key is 
pressed, a certain amount of time elapses— W indows records it. It records what happened, when it hap- 
pened, and which window (and thus which application) it happened to, packs the information into a little 
bundle, and sends it to that application's message queue. A message queue is nothing more than a list of 
messages that have been received by W indows but have not yet been processed by the application (much 
like huge lines to get on roller coasters). Figure 1.2 shows how the event-driven W indows operating system 


works internally. Keep in mind that this diagram is rather simplified. 


The Operating 


Application 
Message 


Pump 


Input Device 


(usually Keyboard 


or mouse) 


Application 
Message 
Queue 


Message 
Handler 
For Application 
(WNDPROC) 


T he following messages are stored in the «sc structure 


typedef struct tagMSG 
HWND hwnd; 

UINT message; 
PARAM wParam; 
LPARAM lParam; 
DWORD time; 
POINT pt; 

} MSG, *PMSG; 


Figure 1.2 


Simplified schematic of the 
inner workings of Windows 
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T he members of the mse structure are explained in Table 1.1. 


Table 11 MSG Members 
Member Purpose 


hwnd The window handle corresponding to the window that is to 
receive the message 


message The type of message received (WM *) 


wPara O ne of the parameters for the message. It is context-sensitive. 
Each WM | message has a different meaning for wParam. 

ТРага One of the parameters for the message. It is context-sensitive. 
Each WM | message has a different meaning for 1Param. 

time Time when this message occurred 

pt Cursor coordinate at time of the message, specified in 


screen coordinates 


WINDOW PROCEDURES 


Each W indows application is responsible for checking its message queue for waiting messages. If there are 
any, it must either process them or pass them along to the default processing function. If this is not done, 
the messages will just pile up, your application will stop responding, and you might lock up the system. 


H andle messages by using a window procedure. H eres what one looks like: 


LRESULT CALLBACK WindowProc( 
HWND hwnd, // handle to window 
UINT uMsg, // message identifier 
WPARAM wParam, // first message parameter 
LPARAM lParam // second message parameter 
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T his returns a value dependent on the message received (usually 0). Table 1.2 explains the purpose of 
the parameters. 


Table 12 WindowProc Parameters 
WindowProc Parameter Purpose 


hwnd The window for which the message is bound 
(msg. hwnd) 

uMsg The type of message (msg.message) 

wParam A parameter of the message (msg .wParam) 

lParam A parameter of the message (тѕо.1Рагап) 


NOTE 
Your window procedure will not be 


named Wi ndowProc.You сап name it eH А 

t all that? It’s time to start coding! 
anything you wish, as long as it has the pokey mats 9 
same parameter list and returns ап 


LRESULT and is a CALLBACK function. 
Later, you will see that | have given my 
window procedure the cunning name 
TheWindowProc, so named because I 
only ever deal with a single window. 


THE WINIVIAIN FUNCTION 


To explain the basic W indows stuff, we'll be using 


IsoH ex1 1.cpp. Start aW IN 32 application work- NOTE 

space, апа add IsoH ex1 1.срр into it. It is the only AS much as! don't want this book to be 
file required for this example. Take a few moments nothing more than a code dump, I’m 

to peruse the code T here isnt much, so it shouldnt including the full listing for 


take long. IsoHex1 1.срр here.This will be one of 
the only dumps— I promise. 
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/ ЖЖЖЖЖЖЖЖЖЖЖЖЖЖЖЖ KKK KK KKK KKK KK KK KKK KKK KKK KK KK KKK KK KK KKK KKK KK KK KKK KKK KKK KK KK KKK 


TsoHexl_l.cpp 

Ernest S. Pazera 

08APR2000 

Start a WIN32 Application Workspace, add in this file 


No other libs are required 
KI KKK KKK IKK IK KK IKK IKK IK KK KK IKK IK KK KK IKK IK KK KK IK KK IKK KK KK KKK KK KK KK KK KK | 


////////////////////////////////////////////////////////////////////////////// 
/ / INCLUDES 
ИИ! 
ІМейпе WIN32_LEAN_AND_MEAN 


jdinclude <windows.h> 


ПИ! 
//DEFINES 
///////////////////////////////////////////////////////////////////////////// 
//name for our window class 

dtdefine WINDOWCLASS "ISOHEXI" 

//title of the application 

ІМейпе WINDOWTITLE "IsoHex 1-1" 


////////////////////////////////////////////////////////////////////////////// 
//PROTOTYPES 
////////////////////////////////////////////////////////////////////////////// 
bool Prog_Init();//game data initializer 

void Prog_Loop();//main game loop 

void Prog_Done();//game cleanup 


///////////////////////////////////////////////////////////////////////////// 
//GLOBALS 
///////////////////////////////////////////////////////////////////////////// 
HINSTANCE hInstMain=NULL;//main application handle 

HWND hWndMain=NULL;//handle to our main window 


////////////////////////////////////////////////////////////////////////////// 
//WINDOWPROC 
////////////////////////////////////////////////////////////////////////////// 
LRESULT CALLBACK TheWindowProc(HWND hwnd,UINT uMsg,WPARAM wParam,LPARAM 1Param) 
{ 


//which message did we get? 
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switch(uMsg) 

{ 

case WM_DESTROY://the window is being destroyed 
{ 


//tell the application we are quitting 
PostQuitMessage(0); 


//handled message, so return 0 
return(0); 


}break; 
case WM_PAINT://the window needs repainting 
{ 
//a variable needed for painting information 
PAINTSTRUCT ps; 


//start painting 
HDC hdc=BeginPaint(hwnd,&ps); 


///////////////////////////// 
//painting code would go here 
ILILILILIL IITE LHI 


//end painting 
EndPaint(hwnd,&ps); 


//handled message, so return 0 
return(0); 
}break; 


//pass along any other message to default message handler 
return(DefWindowProc(hwnd,uMsg,wParam,lParam)); 


////////////////////////////////////////////////////////////////////////////// 
//WINMAIN 
ПИ 
int WINAPI WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR 
lpCmdLine,int nShowCmd) 

{ 
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//assign instance to global variable 
hInstMain=hInstance; 


//create window class 
WNDCLASSEX wex; 


//set the size of the structure 
wcex.cbSize=sizeof (WNDCLASSEX) ; 


//class style 
wcx.style-CS OWNDC | CS HREDRAW | CS VREDRAW | CS DBLCLKS; 


//window procedure 
wcx.lpfnWndProceTheWindowProc; 


жей 


//class extra 
wcx.cbClsExtra-0; 


O 


//window extra 
wcx.cbWndExtra=0; 


//application handle 
wcx.hInstance-hInstMain; 


//icon 
wex.hIcon=LoadIcon(NULL, IDI_APPLICATION); 


//cursor 
wex.hCursor=LoadCursor(NULL, IDC_ARROW) ; 


//background color 
wcx.hbrBackground-(HBRUSH)GetStockObject(BLACK BRUSH); 


/ /men 
wcx.lpszMenuNamesNULL; 


//class name 
wcx.lpszClassName-WINDOWCLASS; 


//small icon 
wcx.hIconSmsNULL; 
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//register the window class, return 0 if not successful 
if(!RegisterClassEx(&wcx)) return(0); 


//create main window 
hWndMaineCreateWindowEx(O,WINDOWCLASS,WINDOWTITLE, WS BORDER | WS_SYSMENU 
| М5 VISIBLE,0,0,320,240, NULL, NULL, hInstMain,NULL) ; 


//error check 
if(!hWndMain) return(0); 


//if program initialization failed, return with 0 
if(!Prog_Init()) return(0); 


//message structure 
MSG msg; 


//message pump 

for(;;) 

{ 
//look for a message 
if (PeekMessage(&msg,NULL,0,0,PM_REMOVE) ) 
{ 


//there is a message 


//check that we aren’t quitting 
if(msg.message==WM_QUIT) break; 


//translate message 
TranslateMessage(&msg); 


//dispatch message 
DispatchMessage(&msg) ; 


//run main game loop 
Prog_Loop(); 


//clean up program data 
Prog_Done(); 
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//return the wparam from the WM_QUIT message 
return(msg.wParam) ; 


///////////////////////////////////////////////////////////////////////////// 
//INITIALIZATION 
///////////////////////////////////////////////////////////////////////////// 
bool Prog_Init() 
{ 
//////////////////////////////////// 
//your initialization code goes here 
ИИ AAT TTT TAT TTT 


return(true);//return success 


////////////////////////////////////////////////////////////////////////////// 
//CLEANUP 
ИИ ILII LA AAAA AA 
void Prog_Done() 
{ 

////////////////////////// 

//cleanup code goes here 

////////////////////////// 


ПИ ИИ 
//MAIN GAME LOOP 
///////////////////////////////////////////////////////////////////////////// 
void Prog Loop() 
{ 

/////////////////////////// 

//main game logic goes here 

ИИ ИИ ҮТҮ 
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Figure 1.3 shows what IsoH ех1 1 looks like when it is running. 


imi IsoHex 1-1 


Figure 1.3 


IsoH ех1 15 output. 
Not much to look at, 
is it? 


W hen talking about W indows programming, we always start with winMain. Оп other platforms, the entry 
point for a program is the main() function. N ot so in W IN 32. Instead, we have a WinMain function, and 
the declaration looks like this: 


int WINAPI WinMain( 


HINSTANCE hInstance, // handle to current instance 
HINSTANCE hPrevInstance, // handle to previous instance 
LPSTR lIpCmdLine, // command line 

int nCmdShow // show state 


DE 


T his returns an exit code for the application (0 is the normal termination). Table 1.3 explains the parame 
ter list. 


Table 1.3 WinMain Parameters 


WinMain Parameter Purpose POTE 
Unlike window 
hInstance Handle to the current instance procedures, our 
WinMain func- 
hPrevInstance O bsolete tion will always 
lpCmdLine String containing parameters passed on the be named 
command line.W e will not be using this. ШШЩ 
nCmdShow Integer stating how the main window should 


be shown.We will be ignoring this also. 
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HINSTANCE 


For our purposes, the only parameter of any significance is hInstance. ІП IsoH ех1 1.срр, you will see 
that | took the value of hInstance and assigned it to a global variable called ninstMain: 


//copy instance handle into global variable 
hInstMainehInstance; 


We сап write programs so that doing this is unnecessary, where winMain passes the value of hInstance to 
whatever function needs it (many times, nInstance 15 never used for anything). Н owever, most game 

code that I've written or seen written has placed hinstance's value into a global variable, whether it is 
used or not. 


WINDOW CLASS 


Creating a window class is the next task that the program undertakes. A window class is nothing more 
than a structure that describes a type of window. You need oneif you want to make your own types 


of windows. 

typedef struct _WNDCLASSEX { 
UINT cbSize; 
UI style; 
NDPROC lpfnWndProc; 
int cbClsExtra; 
Tr cbWndExtra; 
HINSTANCE hInstance; 
HICON hIcon; 
HCURSOR hCursor; 
HBRUSH hbrBackground; 
LPCTSTR lpszMenuName; 
LPCTSTR lpszClassName; 
HICON hIconSm; 

| WNDCLASSEX, *PWNDCLASSEX; 


INTRODUCTION TO WINS2 PROGRAMMING 


О kay...theres a lot of stuff in this structure, and not much of it is very intuitive A breakdown of 
WNOCLASSEX'S members can be found in Table 1.4. 


Table 1.4 WNDCLASSEX Members 
WNDCLASSEX Member Purpose 


cbSize The size of the W N DCLASSEX structure 

style Class styles (described in text below) 

lpfnWndProc Pointer to а windowproc, the function that we 
use to process window messages 

cbClsExtra Extra bytes to allocate for the class structure 

cbWndExtra Extra bytes to allocate for the window 

hInstance A pplication handle 

hIcon Icon to show in the upper-left corner 

hCursor Mouse cursor to use 

hbrBackground Brush to use for background color 

lpszMenuName The menu to use for this window class 

lpszClassName N ame of the class 

hIconSm Small icon to associate with the class 


Following is the code you will use to set up your window class: 


//create window class 

WNDCLASSEX wcx; 

//set the size of the structure 

wex.cbSize=sizeof  (WNDCLASSEX) ; 

//cla 

wcx.style-CS OWNDC | CS_HREDRAW | CS_VREDRAW | CS_DBLCLKS; 

//window procedure 
] 
a 
С 


wcx.lpfnWndProc-TheWindowProc; 
//class extra 
wcx.cbClsExtra-0; 

//window extra 
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wcx.cbWndExtra-0; 
/lapplication handle 
wcx.hInstance-hInstMain; 
/lapplication ico 
wcx.hIcon-LoadIcon(NULL,IDI. APPLICATION); 
//cursor 
wcx.hCursor-LoadCursor(NULL,IDC ARROW); 
//background brush 
wcx.hbrBackground-(HBRUSH)GetStockObject(BLACK BRUSH); 
//me 
wcx.lpszMenuName-NULL ; 

//class name 
wcx.lpszClassName-WINDOWCLASS; 
//small icon 

wcx.hIconSmsNULL; 


Several of the values, like cbSize, nInstance, and so on, are self-explanatory. l'Il explain those that are 
less so. 


WCX STYLE 


T his is the window class style. It's a series of flags that start with cs_ values, combined using the bitwise 
OR Operator ( | ). 


= CS_OWNDC tellsW indows that windows of this class will each have their own device context (D C). 
D Cs will be explained in more detail in the next chapter. 

= CS HREDRAW and cs vREDRAW tells W indows that if the windows created with this class are resized 
vertically or horizontally, the window must be repainted. 

= CS DBLCLKS tells W indows that you want the window to respond to double-clicks. 


WCXsLPFNWINDFPROC 


T his value is a pointer to a window procedure (which | mentioned briefly a little earlier). T his member has 
been assigned to TheWindowProc, which is a function that you write to handle all the messages your win- 
dow will receive. 


WCXsHICON 


| promised | wouldnt add any new handle types until the next chapter. | lied. T his is a handle to an icon, 
which I'm sure youre familiar with. If you have a normal-looking window, with a border and a system 
menu and so on, this is shown in the upper-left corner and on theTaskbar. W e use Loadicon to load 
ІПІ APPLICATION, Which is a system icon. 
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wcx.cbWndExtra-0; 
/lapplication handle 
wcx.hInstance-hInstMain; 
/lapplication ico 
wcx.hIcon-LoadIcon(NULL,IDI. APPLICATION); 
//cursor 
wcx.hCursor-LoadCursor(NULL,IDC ARROW); 
//background brush 
wcx.hbrBackground-(HBRUSH)GetStockObject(BLACK BRUSH); 
//me 
wcx.lpszMenuName-NULL ; 

//class name 
wcx.lpszClassName-WINDOWCLASS; 
//small icon 

wcx.hIconSmsNULL; 


Several of the values, like cbSize, nInstance, and so on, are self-explanatory. l'Il explain those that are 
less so. 


WCX STYLE 


T his is the window class style. It's a series of flags that start with cs_ values, combined using the bitwise 
OR Operator ( | ). 


= CS_OWNDC tellsW indows that windows of this class will each have their own device context (D C). 
D Cs will be explained in more detail in the next chapter. 

= CS HREDRAW and cs vREDRAW tells W indows that if the windows created with this class are resized 
vertically or horizontally, the window must be repainted. 

= CS DBLCLKS tells W indows that you want the window to respond to double-clicks. 


WCXsLPFNWINDFPROC 


T his value is a pointer to a window procedure (which | mentioned briefly a little earlier). T his member has 
been assigned to TheWindowProc, which is a function that you write to handle all the messages your win- 
dow will receive. 


WCXsHICON 


| promised | wouldnt add any new handle types until the next chapter. | lied. T his is a handle to an icon, 
which I'm sure youre familiar with. If you have a normal-looking window, with a border and a system 
menu and so on, this is shown in the upper-left corner and on theTaskbar. W e use Loadicon to load 
ІПІ APPLICATION, Which is a system icon. 
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WCX: HCURSOR 


T his is another handle type— this time, to a mouse cursor. In this case, LoadCursor 15 used to load 
1DC_ARROW, Which is the customary arrow that you find every day. 


WCX: HRACKGROUND 


T his is yet another handle type— this time, a brush. Briefly, a brush is used to fill in areas with solid colors 
or patterns. GetStockObject is used to specify a black brush. T he (HBRUSH) typecast is necessary because 
GetStockObject returns void*. 


WCXsLPSZCLASSNAME 


T his is the name of the window class. If you take а peek up near the top of IsoH ех1 1.срр, you will see 
the following lines: 


dtdefine WINDOWCLASS "IsoHex1" 
dtdefine WINDOWTITLE "IsoHex Example 1-1" 


| dont usually use #define much (1 prefer const). Since WINDOWCLASS is used in only two places, | didnt 
really see a need to use const. WINDOWTITLE is used only once (when we create our window later), so | felt 
that 4define was adequate for our needs. 


After you have filled out the window class struct, you use the Regi sterC1assEx function to register it 
with W indows.T hereis a small amount of error checking with the code. If the function returns NULL, you 
were unable to register the class, and you return 0 from winMain, terminating the application. 


N otice that исх is not a global variable. You dont really need to worry about it after you have set it up and 
registered it, because you can just use the class's name. 


O nce you have registered a window class, you are ready to make a window and start processing messages. 
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THE MESSAGE Pump 


l'II show you the remainder of winMain all at once, and then I'll take apart the pieces. Figure 1.4 is a flow- 
chart of the process. 


Figure 1.4 


4 
| Flowchart of the 


message pump 


4 Is there a message? 


Translate message 
(for key conversion 
to characters) 


Dispatch message 
to proper W NDPROC 


Runa 
single frame of the game 


//create main window 
hWndMain=CreateWindowEx(0,WINDOWCLASS ,WINDOWTITLE, 
WS_SYSMENU| WS_CAPTION | WS_VISIBLE,0,0,320,240, 
NULL,NULL,hInstMain,NULL) ; 
if(!hWndMain) return(0);//error check 
if(!Prog_Init()) return(0);//if program initialization failed, then return with 0 
MSG msg;//message structure 
for(;;) //message pump 
{ 
if (PeekMessage(&msg,NULL,0,0,PM_REMOVE) ) 
{ 
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if(msg.message==WM_QUIT) break; 
TranslateMessage(&msg); 
DispatchMessage(&msg); 


else NOTE 


{ Some of the lines are broken into two. 
Prog_Loop(); This is because the book format isn’t 
} wide enough to contain them. Just 
} keep in mind that these lines actually 
Prog_Done(); exist as only one line in the real code. 
return(msg.wParam) ; 


CREATING A WINDOW 


T he first line of this segment of code creates your main window by calling createWindowEx: 


НИМО CreateWindowEx( 
DWORD dwExStyle, // extended window style 
LPCTSTR lpClassName, // registered class name 
LPCTSTR lpWindowName, // window name 


DWORD dwStyle, // window style 
int x, // horizontal position of win- NOTE 
d 
D | - | Other books tend to 
nt y, // vertical position of window т 
жое a ШЕ use the CreateWindow 
и о function rather than 
nt nHeight, // window height CreatelandowexcThe 
E D hWndParent, // handle to parent or owner only difference between 
window CreateWindow and 
HMENU hMenu, // menu handle or child identifi- CreateWindowEx is that 
er CreateWindow lacksa 
HINSTANCE hInstance, // handle to application instance ЗАК Тет 
LPVOID lpParam // window-creation data 


T his returns a handle to the newly created window. 


DWEXSTYLE 


T his parameter specifies the extended window style. | have placed 0 here because extended styles arent 
needed for such a simple application. T he help files have a comprehensive list of these flags under the entry 
for CreateWindowEx. 
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LPCLASSNAME 


T his parameter specifies the name of the window class to which this window belongs. In our case, this is 
WINDOWCLASS. 


Lr DliNDOLUDINRNE 


T his parameter specifies the text that will be displayed in the title of the window (if it has one) and also 
in theTaskbar. We are using WINDOWTITLE. 


DWSTYLE 


T his parameter contains one or more ws_~ flags, which are listed next. T hese flags (or combinations there 
of ) change the appearance of your window. Some flags also change the way a window behaves. 


WS_BORDER Creates a window with a thin line border. 

WS CAPTION Creates a window with a title bar and a thin line border. 
WS_CHILD Creates a child window. Cannot be a pop-up. Cannot have a menu bar. 
WS CHILDWINDOW бее WS CHILD. 

WS HSCROLL Creates a window with a horizontal scroll bar. 

WS ICONIC Creates a window that is initially minimized. 

WS MAXIMIZE Creates a window that is initially maximized. 

WS MAXIMIZEBOX Creates a window with a maximize button. 

WS MINIMIZE Seews ICONIC. 

WS MINIMIZEBOX Creates a window that is initially minimized. 

WS OVERLAPPED Creates a window that has a border and title bar. 

WS OVERLAPPEDWINDOW Combines WS. OVERLAPPED, WS. CAPTION, WS SYSMENU, М5 THICKFRAME, 
WS MINIMIZEBOX, and WS MAXIMIZEBOX. 

WS POPUP  Createsa pop-up window. 

WS POPUPWINDOW Combines WS BORDER, WS, POPUP, and WS, SYSMENU. 
WS SIZEBOX Creates a window that has a sizing border. 

WS. SYSMENU Creates a window with a window menu on its title bar. 

WS THICKFRAME бее 45 SIZEBOX. 

WS TILED Se@WS_OVERLAPPED. 

WS TILEDWINDOW See WS_OVERLAPPEDWINDOW. 

WS VISIBLE Createsan initially visible window. 

WS VSCROLL Creates a window with a vertical scrollbar. 


IsoH ex1 Lcpp uses ws CAPTION, WS SYSMENU, and WS_VISTBLE. In the future, ws РОРУР and ws vrsr- 
BLE Will be used. 
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Ха Y 
T hese parameters contain the upper-left corner of the window. You are using 0,0. 


NWIDTH, NHEIGHT 
T hese parameters contain the width and height of the window. You are using 320,240. 


NHWNDPARENT 


W indows can be children of other windows (using the иѕ сніго window style), or they can be “owned” 
by other windows. T he owner of either of these types of windows is called a paret. You are using NULL 
because this window has no parent. 


HIYIENU 
M ost types of windows can make use of menus. In your case, you arent using a menu, SO pass NULL. 


HINSTANCE 
T he application instance that owns the window (such as hInstMain). 


LPPARAM 
Extra creation data. You don't have any, So pass NULL. 


After we call CreateWindowEx, check to make sure that you window actually exists by checking that it is 
not NULL. If it is NULL, the program exits immediately, without even whimpering. (T heoretically speaking, 
if it does fail, you want to give the users of the application a nice message box containing the 

reason why the program halted so abruptly. Traditionally, these error messages are as cryptic as you can 
make them.) 


OTHER INITIALIZATION 


N ext, call Prog InitO, which is your user-supplied bit of initialization code. Later, you'll be initializing 
DirectD raw, Loading Bitmaps, and anumber of other things, all in this function. For now, the function 
simply returns true, which is good, because if it returned false, the program would terminate. 


On the next line is the declaration of a variable named msg, which is of type msc. T his variable will be 
what you use to look for, grab, translate, and dispatch W indows messages. I'll cover W indows messages 
later in this chapter. You've already seen the msc struct, but here it is again: 
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typedef struct tagMSG { 
HWND hwnd; 

UINT message; 
PARAM wParam; 
LPARAM lParam; 
DWORD time; 

POINT pt; 

} MSG, *PMSG; 


If you skip down to later in the code, you'll see that it checks the message member against ww Quir to 
determine whether or not to exit, but other than that, you just send a pointer to msg to functions. 

W indows handles the rest, and thank goodness! (1 once developed a messages-based event queue for DO S 
by trapping interrupts, and it was a nightmare) 


N ow comes the message pump itself— the most important but least interesting part of winMain. It's the 
part that does the repetitive task of talking to W indows. It is contained in a for loop that never ends 
(well, theoretically never ends). 


T he message pump does the following (refer to Figure 1.4 for a graphical view): 


1. Checks for a message. 
2. If there is a message, processes that message. 
3. If there is no message, runs a single frame of the game. 


CHECKING FOR MESSAGES 


То check for a message, use PeekMessage. T his is a departure from normal W indows programming. M ost 
applications use GetMessage, because nongame applications do very little except in response to user input. 
A game, on the other hand, even if it is turn-based, still has tasks to perform when there are no messages. 


BOOL PeekMessage( 
LPMSG lpMsg, // message information 
HWND hWnd, // handle to window 
UINT wMsgFilterMin,  // first message 
UINT wMsgFilterMax, // last message 
UINT wRemoveMsg // removal options 
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T his returns 0 if there is no message and nonzero if a message is found. Table 1.5 explains the 
parameter list. 


Table 15 PeekMessage Parameters 
PeekMessage Parameter Purpose 


1рМ$9 Pointer to а MSG structure that will be filled 
with message information if there is one 
available 

hWnd Specifies the handle of the window for which 


we are looking for messages. Passing NULL 
will get messages from any window in the 


application. 
wMsgFilterMin Lowest value of messages we are looking for 
wMsgFilterMax Highest value of messages we are looking for. 


Specifying 0 in both wMsgFilterMin and 
wMsgFilterMax will look for any message. 


wRemoveMsg Either the value PM REMOVE Or PM NOREMOVE. 
Tells the function to remove or not remove 
the message from the message queue. 


PROCESSING MESSAGES 


You must do three things in order to process a message. First, check to see if the msg message IS а 
WM. QUIT. If it is, break out of the infinite for loop. 


N ext, call TranslateMessage: 


BOOL TranslateMessage( 
CONST MSG *1рМ$9 // message information 
Е 


T his function takes WM_KEYDOWN and ww KEvuP messages and translates them into им cHAR messages. (It 
also translates uM svskEvpowN and WM_SYSKEYUP into wM sYscHAR.) T he only parameter is an LPmse. It 
returns 0 if the message is not translated and nonzero if it is. Either way, you dont really care. If there is 
translation to be done, you just want it done. 
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Finally, call Di spatchMessage: 


LRESULT DispatchMessage( 
CONST MSG *lpmsg // message information 
ys 


T his function takes an Lemse, just like TranslateMessage does, and it calls the appropriate message han- 
dler (usually a window procedure). T he return value of DispatchMessage depends on what value is 
returned by the message handler it calls. 


RUNNING A SINGLE FRAME or THE GAME 


If there is no message, call Prog Loop, which runs a single frame of your game. Currently, there is noth- 
ing in Prog Loop. 


CLEANUP AND ÈXIT 


After the infinite for loop has been exited, there are just two more lines, and my explanation of winMain 
is done. 


T he next-to-last thing is calling Prog Done O, which is the user-defined function that contains any 
cleanup code that you need. 


And finally, you return the value of msg’s wparam.T his specifies your application's exit code. If the pro- 
gram ends as a result of PostQuitMessage, the value passed to that function will bein msg.wparam. Zero 
indicates normal termination. 


| know I've gone rather quickly through this introductory stuff, and maybe, if you're new to the concept of 
W IN 32 programming, | left you hanging just alittle. | ask you to bear with me, because my goal is to get 
to the good stuff as quickly as possible For more information on any of the functions I ve listed here, take 
a look at the M SDN documentation (the help files). It has more information than you really want or 

need on how everything works. T he winMain function is rather dull; it's almost always written exactly the 
same way. 


THE WINDOW PROCEDURE 


Н eres the minimal windowproc that is used іп IsoH ех1 1: 


LRESULT CALLBACK TheWindowProc(HWND hwnd,UINT uMsg,WPARAM wParam,LPARAM lParam) 
{ 
switch(uMsg) 
{ 
case WM_DESTROY://the window is being destroyed 
{ 
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PostQuitMessage(0);//tell the application we are quitting 
return(0);//handled message, so return 0 

}break; 

case WM_PAINT://the window needs repainting 

{ 


PAINTSTRUCT ps; 

HDC hdc=BeginPaint(hwnd,&ps);//start painting 

//painting code would go here 

EndPaint(hwnd,&ps);//end painting 

return(0);//handled message, so return 0 
}break; 


} 


return(DefWindowProc(hwnd,uMsg,wParam,lParam)); 


T he skinny of the whole thing is this: depending on what message you are handling (such as the contents 
of the имѕо parameter), you execute different code; thus you have the switch. If you handle a message, you 
have to return 0. If you dont handle the message, you pass the parameters on to the default message pro- 
cedure (DefWindowProc), which handles the rest of our messages. 


T he two messages that need to be taken саге of are wM_DESTROY and wM PAINT. T here are a number of 
WM. * messages, everything from key presses and key releases to mouse movement and mouse button state 
changes to timers and so on. Some of them are cryptic, and you wont be using very many. 


WM DESTROY is sent when the window is being destroyed. It's there to allow you to clean up anything you 
might be doing specific to the window. All your data is elsewhere, so you dont have to do much. Y ou just 
have to tell the application that you are quitting, with PostQuitMessage(0). T he parameter for 
PostQuitMessage IS an error code, and 0 specifies normal termination. 


VOID PostQuitMessage( 
int nExitCode // exit code 


T his function returns no value, and it takes as a parameter the exit code for the application. 


WM PAINT is sent whenever a window needs to be repainted. U sually this is when a minimized window is 
restored or a background application is brought to the front, if there were overlapping areas. 


In order to repaint as little as possible W indows uses a struct called PAINTSTRUCT, which contains infor- 
mation about what part of the window is to be redrawn: 


typedef struct tagPAINTSTRUCT { 
НОС һас; 
BOOL fErase; 
RECT rcPaint; 
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BOOL fRestore; 
BOOL fIncUpdate; 
BYTE rgbReserved[32]; 
} PAINTSTRUCT, *PPAINTSTRUCT; 


l'm not going to go too much into this, because you dont use PAINTSTRUCT Outside of your handling of a 
WM PAINT message, and even in that, you'll never have much more code than what you've already got. 


So, in the wM_PAINT handler, you declare a PAINTSTRUCT variable and then call BeginPaint, passing the 
parameters of the window handle (hwnd) and a pointer to your PAINTSTRUCT.T he return value you assign 
to a new нос variable called нас. Dont worry about what an Hoc is right now. All will be explained in 
Chapter 2. 

HDC BeginPaint( 


HWND hwnd, // handle to window 
LPPAINTSTRUCT lpPaint // paint information 


N ow youd presumably do something with the hdc. Right now, there isnt anything that needs doing (hey, 
how hard can it be to manage a black rectangle?) 


Finally, you call EndPaint, passing hwnd and a pointer to your PAINTSTRUCT again. T his lets W indows 
know that you've done your job of repainting. T hen 0 is returned. 
BOOL EndPaint( 


HWND hWnd, // handle to window 
CONST PAINTSTRUCT *lpPaint  // paint data 


W hy must you do all this?W dl, if you dont, W indows will whine “PAINT YOUR WIN DOW ! PAINT 
YOUR WINDOW "This BeginPaint/ EndPaint stuff is there for no other reason than to shut 
W indows up and have it leave you in peace— a noble goal. 


SENDING MESSAGES TO A WINDOW 
To send a window message, you just need to use the function sendMessage: 


LRESULT SendMessage( 
HWND hWnd, // handle to destination window 
UINT Msg, // message 
WPARAM wParam, // first message parameter 
LPARAM 1Param // second message parameter 
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T he return value depends on what is returned from the windowproc that is called. Table 1.6 explains the 
parameters. 


Table 1.6 SendMessage Parameters 
SendMessage Parameter Purpose 


hWnd W indow handle to which that you are sending the 
message 

Msg The message you are sending (им_*) 

wParam First parameter of the message 

lParam Second parameter of the message 


T here is also a function called PostMessage. It does the same thing, sort of. SendMessage sends the mes- 
sage immediately to the window, where it will be processed and then returned, whereas Postmessage just 
adds the message to the list of events that the window has yet to handle. PostMessage has the same 
parameter list as SendMessage, but its return type 15 в001, and it is nonzero on success and 0 on failure. 


USING Иймоощм MESSAGES TO 
PROCESS INPUT 


You'll use messages to process any input your window receives. If you're about to ask why I'm not using 
DirectInput, | ask you to check how thick this book is already and then factor in a chapter on DI. Also, 
for our purposes, window messages will suffice. 


KEYBOARD MESSAGES 
You'll use three 


messages for the : * Messages 
keyboard. T here are тез Lu Е м. 


many more than Keyboard Message Meaning of wParam Meaning of IParam 
this, but you wont 

need them. Table WM_KEYDOWN Virtual key code (ук_*) Shifts state/repeat 

1.7 shows the count/flags 

meaning of wParam ММ. KEYUP Virtual key code (Vk *) Shifts state/repeat 
and 1Param for count/flags 

these messages. WM_CHAR Character code (ASCII) Shifts state/repeat 


count/flags 
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WM_KEYUP/SWM_KEYDOWN 


WM_KEYDOWN and WM_KEYUP are very similar in their NOTE 

use but are called at separate times. им _KEYDOWN is Not all keys have a ҮК * constant asso- 

called when a key is pressed, and им xtvuP is called ciated with them.T he most noticeable 

when a key is released. (T his aint rocket science, lack is the alphabetic and non-numpad 

| know.) number keys. The constants VK 0 
through VK. 9 have the same values as 

Table 1.8 lists some vk constants and their values. 0 through 9, and ҮК A through Vk. 7 


have the values A through Z. None of 
the VK_* constants for numbers or 
letters actually exist. 


Table L8 МК * Constants andT heir Values 


VK_BAC 0x08 VK_RWIN 0x5C WIS ІР 0x74 
VK TAB 0x09 VK APPS 0x5D VK F6 0x75 
VK RETURN  OxOD VK NUMPADO 0x60 VK F7 0x76 
VK SHIFT 0x10 VK NUMPADI 0x61 VK F8 0x77 
VK CONTROL 0х11 VK NUMPAD2 0x62 VK F9 0x78 
ҮК MENU 0x12 VK NUMPAD3 0x63 VK F10 0x79 
VK PAUSE 0x13 VK NUMPADA 0x64 VK_F11 Ox7A 
VK ESCAPE Ox1B VK NUMPAD5 0x65 WIS E112 0х7В 
VK_SPACE 0x20 VK_NUMPAD6 0x66 VK_F13 0x7C 
VK PRIOR 0x21 VK NUMPAD7 0x67 VK F14 0х70 
VK_NEXT 0x22 VK NUMPAD8 0x68 VK F15 Ох7Е 
VK_END 0x23 VK_NUMPAD9 0x69 VK_F16 Ox7F 
VK_HOME 0x24 VK MULTIPLY 0x6A VK F17 0x80 
WI& ПЕРІ 0x25 VK ADD 0x6B VK F18 0x81 
VK UP 0x26 VK SEPARATOR | 0x6C VK F19 0x82 
VK RIGHT 0x27 VK SUBTRACT 0x6D VK F20 0x83 
VK DOM 0x28 VK DECIMAL Ox6E VK_F21 0x84 
V SELECT 029 VK_DIVIDE 0хбЕ VK_F22 0x85 
VK_PRINT 0х2А VK_F1 0x70 VK_F23 0x86 
VK INSERT 0х2р VK F2 0x71 VK F24 0x87 
УК DELETE (ДЕ Wits 0x72 VK NUMLOCK 0x90 
VK LWI Ox5B VK_F4 0x73 VK_SCROLL 0x91 
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For example, if you wanted to write a handler that closed the main window in response to the user's press- 
ing the Esc key, you would write the message handler like so: 


case WM KEYDOWN: 
{ 


if (wParam==VK_ESCAPE) 
{ 
DestroyWindow(hWndMain);//destroy main window 
} 
return(0);//we handled the message 
}break; 


WMI CHAR 


WM_CHAR, ОП the other hand, responds to characters that the keyboard driver has translated into actual 
characters. T he contents of wParam are the ASCII values, such as a, b, с, and so forth. In many cases, you 
dont care about what the key's ASCII code is (you only care if a key is down or not), so you'll use this 
message only when you are inputting strings. 


T he last word on keyboard input has nothing to do with messages. R esponding to WM_KEYDOWN and 

WM KEYUP usually gets you where you want to go, but not always. It’s absolutely awful for just seeing if a 
key is down or not, especially if the user switches applications between the calls of wM_kKEYDOWN and 

WM KEYUP.TO fix this, in those cases where you only care whether a key is up or not (to move a unit or 
character or something), you use GetAsyncKeyState: 


SHORT GetAsyncKeyState( 
int vKey // virtual-key code 
Ja 


vKey represents the virtual key for which you are trying to read the state. In the return value, the most sig- 
nificant bit will be 1 if the key is down or 0 if the key is up. Because the return value is a SHORT (a signed 
type), you can check to see if a key is down by checking to seeif the return value is negative: 


if (GetAsyncKeyState(VK_ESCAPE) <0) 
{ 


//stuff to do if the escape key is down 
} 


| == | 1S0MmeETRIC GAME PROGRAMMING WITH, DIRECTX 7,0 


T here are a few extra үк > constants that only GetAsyncKeyState recognizes. Т hese аге listed in 
Table 1.9. 


Table 19 VK * Constants that 


Work Only with 
GetAsyncKeyState 
" NOTE 
VK * Code HexValue Th au) 
VK LSHIFT 0хА0 ues listed inTable 1.9 
и with any of the WM_KEY* 
VK_RSHIFT 0хА1 messages. T hey just 


won't work. 


VK LCONTROL OxA2 


VK RCONTROL = 0x43 
VK LMENU ОХА4 


VK_RMENU ОХА5 


Mouse MESSAGES 


T here are a bunch of these, but you need only about а handful. Luckily, they are all formatted the same as 
far as the information passed in wParam and 1Param. Table 1.10 lists the им_* messages you will be con- 
cerned with. 


Table 1.10 Mouse Messages 


Message When It Happens 

WM_MOUSEMOVE The mouse has been moved. 
WM_LBUTTONDOWN The left mouse button has been pressed. 
WM_LBUTTONUP The left mouse button has been released. 
WM_RBUTTONDOWN The right mouse button has been pressed. 
WM_RBUTTONUP The right mouse button has been released. 
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Its important to note here that “left” and “right” have some subjective meanings. For example, if you 
reverse your mouse buttons under your W indows settings, the buttons will be swapped as far as which mes- 
sages they generate (as shown in Figure 1.5). In my opinion, this is one of the good features of W indows. 
We dont want to alienate the lefties! 


Figure 1.5 
Reversed mouse buttons 


Generates Generates Generates Generates 
WM RBUTTONDOWN WM LBUTTONDOWN WM LBUTTONDOWN WM RBUTTONDOWN 


Right-Handed Mouse 


T he contents of wParam for a mouse message consist of a number of flags, covering stuff like the state of 
the Shift and Ctrl keys to the state of the mouse buttons. Table 1.11 is a breakdown of these flags. 


Table L11 wParam Flags for Mouse Buttons 
and Shift States 


Mouse Flag Meaning 


CONTROL The Ctrl key is down. 


 LBUTTON The left mouse button is down. 


_MBUTTON The middle mouse button is down. 


_RBUTTON Тһе right mouse button is down. 


ЕЕ The Shift key is down. 
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If you want to check to see if the left mouse button 
is down in your message handler (for example, dur- NOTE 


ing a wM. MOUSEMOVE), do this: You callasoldhelk thi shite of the mause 
//check for left button down buttons using GetAsyncKeyState. 
if (wParam&MK_LBUTTON) However, this will not be correct for users 
{ who reverse the mouse buttons. 


//do something 


} 


1Param contains the x and у position of the mouse cursor. To retrieve these values, use something similar 
to the following code: 


int x=LOWORD(1Param);//x is contained in the lower 16 bits 
int y=HIWORD(1Param);//y is contained in the upper 16 bits 


T he documentation states that you should use the aET_x_LPARAM and GET_Y_LPARAM macros rather than 
the LOWORD and HIWORD macros. Personally, I've not seen a difference. 


OTHER WINDOW MESSAGES 


T here sean to be thousands of window messages you could respond to. If you want to look at the list, 
load up MSDN (the пар files should have come with your V C++ compiler). Go to the index tab, type in 
wM , and look aghast at the long, long list of messages. M any or most of them are of limited use. On 

the M SDN CDs, the messages are pretty well documented, and the meanings of wParam and 1Param are 
made pretty clear. 


It seems kind of bizarre that out of hundreds of window messages, we'll only be using about a dozen, but 
that's just W indows. 


T here is just one miscellaneous message that | should cover wM_ACTIVATEAPP. W ell be using it later. 


ЛІГІ FCTIVHTETBTT 


WM ACTIVATEAPP is sent to an application when it is activated (if another application was the currently 
active one) and when it is deactivated (when the user switches to another application). wParam contains a 
boolean variable that specifies whether or not the current application is the one being activated (a nonzero 
value) or deactivated (a value of 0). 


W hen your application is deactivated, especially when you are using D irectX in full-screen mode, you will 
want to put the application into some sort of “paused” state. It's not a bad idea to do so even when you're 
not in full screen, because if the application isnt active, you dont want to continue executing the game 
until the user reactivates it. 
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Well handle activation with a global variable called bActive: 


bool bActive=false;//start as non-active 
Somewhere in the Prog_Init() function, you'll set bActive to true. 


During Prog_Loop(), you check bActive. If it's false, you just return from the function without doing 
anything. 


if(!bActive) return; 


Finally, you respond to the uM ACTIVATEAPP message: 


case WM ACTIVATEAPP: 
{ 
bActive=(bool )wParam; 
if (bActive) 
{ 
//activation code 


//deactivation code 
} 
}break; 


MANAGING YouR WINDOWS 


T here are a number of functions for managing windows that you'll probably at least want to be 

familiar with. Some of these functions— setWindowPos, MoveWindow, and GetWindowInfo— concern 
themselves with a window's size and position. T he rest of them— SetWindowText, GetWindowText, and 
GetWindowTextLength— Concern themselves with the text displayed in thetitle bar and on theTaskbar. 


SETWINDOWPOS 
BOOL SetWindowPos( 
HWND hWnd, // handle to window 
HWND hWndInsertAfter,  // placement-order handle 
int X, // horizontal position 
int У, // vertical position 
int cx, // width 
int cy, // height 
ОТМТ uFlags // window-positioning options 
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SetWindowPos returns nonzero on success and 0 on failure Table 1.12 lists the parameters and their 
purposes. 


Table 1.12 SetW indowPos Parameters 
SetW indowPos Parameter Purpose 


hWnd Handle to the window you want to reposition 


hWndInsertAfter This is a z-order thing. It’s the handle to another window 
in your application that you want your window to be 
behind. Can also take some constants. 


int X The desired horizontal position of the left edge of 
the window 

int ¥ The desired vertical position of the top edge of 
the window 

int cx The desired width of the window 

int Cy The desired height of the window 

uFlags Flags (see below under “Flags”) 


SetWindowPos can optionally change the z-order, position, and size of a window, depending on the 
parameters you give it. 


Z-ORDER 


If you had more than one window, you could set which one was on top of the others by calling 
SetWindowPos and specifying this. Besides window handles, SetwindowPos also takes a number of con- 
stants in this parameter: 


= НИМО BOTTOM Places the window at the bottom of the z-order. 

= НИМО NOTOPMOST M akes the window a non-topmost window and places it above all other non-topmost 
windows. 

= НИМО TOP Places the window at the top of the z-order. 

= НИМО TOPMOST М akes the window a topmost window and places it at the top of the topmost z-order. 


Some of those explanations sound like gibberish, | know, especially when I’m talking about topmost. 
Topmost windows are windows that are always on top. T hey sort of have their own z-order. Т heT askbar is 
one of these, 
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SetWindowPos returns nonzero on success and 0 on failure Table 1.12 lists the parameters and their 
purposes. 


Table 1.12 SetW indowPos Parameters 
SetW indowPos Parameter Purpose 


hWnd Handle to the window you want to reposition 


hWndInsertAfter This is a z-order thing. It’s the handle to another window 
in your application that you want your window to be 
behind. Can also take some constants. 


int X The desired horizontal position of the left edge of 
the window 

int ¥ The desired vertical position of the top edge of 
the window 

int cx The desired width of the window 

int Cy The desired height of the window 

uFlags Flags (see below under “Flags”) 


SetWindowPos can optionally change the z-order, position, and size of a window, depending on the 
parameters you give it. 


Z-ORDER 


If you had more than one window, you could set which one was on top of the others by calling 
SetWindowPos and specifying this. Besides window handles, SetwindowPos also takes a number of con- 
stants in this parameter: 


= НИМО BOTTOM Places the window at the bottom of the z-order. 

= НИМО NOTOPMOST M akes the window a non-topmost window and places it above all other non-topmost 
windows. 

= НИМО TOP Places the window at the top of the z-order. 

= НИМО TOPMOST М akes the window a topmost window and places it at the top of the topmost z-order. 


Some of those explanations sound like gibberish, | know, especially when I’m talking about topmost. 
Topmost windows are windows that are always on top. T hey sort of have their own z-order. Т heT askbar is 
one of these, 
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FLAGS 


SetWindowPos responds to anumber of flags, which can optionally turn the various other parameters on 
and off: 


= SWP NOACTIVATE Tells SetWindowPos not to activate this window when changing it. 
= SWP NOCOPYBITS Tels SetWindowPos not to copy the contents of the client area. 

= SWP NOMOVE Tals SetWindowPos to ignore x and у. 

" SWP NOSIZE Tells SetWindowPos to ignore cx and cy. 

= SWP NOZORDER Tells SetWindowPos to ignore hWndInsertAfter. 


MoveWinoovw 

BOOL MoveWindow( 
HWND hWnd, // handle to window 
int X, // horizontal position 
int Y, // vertical position 
int nWidth, // width 
int nHeight, // height 


BOOL bRepaint // repaint option 
)3 
Returns nonzero on success or 0 on failure Table 1.13 explains the parameter usage. 


Table 113 MoveW indow Parameters 
MoveW indow Parameter Purpose 


hWnd Handle to the window you are moving 

X The desired horizontal coordinate for the left edge of 
the window 

y The desired vertical coordinate for the top edge of 
the window 

nWidth The desired width of the window 

nHeight The desired height of the window 

bRepaint Specifies whether or not you want the window to 


be repainted. 
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MoveWindow does much the same thing that SetwindowPos does, minus the window position in the 
z-order. 


//resize the window to be 640x480 
MoveWindow(hWndMain,0,0,640,480); 


GETWINDOWINFO 


BOOL GetWindowInfo( 
HWND hwnd, // handle to window 
PWINDOWINFO pwi // window information 


T his function fetches information about a given window (hwnd) in a w1NDOWINFO Structure. It returns 
nonzero on success and 0 on failure. 


T he WINDOWINFO structure looks like this: 


typedef struct tagWINDOWINFO { 
DWORD cbSize; 

RECT  rcWindow; 

RECT  rcClient; 

DWORD dwStyle; 

DWORD dwExStyle; 

DWORD dwWindowStatus; 

UINT cxWindowBorders; 
UINT cyWindowBorders; 
АТОМ atomWindowType; 

ORD wCreatorVersion; 

} WINDOWINFO, *PWINDOWINFO, *LPWINDOWINFO; 
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Table 1.14 explains the members of wINDOWINFO. 


Table 1.14 Members of WINDOWINFO 
WINDOWINFO Member Purpose 


cbSize The size of this structure 

rcWindow A RECT (more on these in Chapter 2) describing 
the area taken up by the window 

rcClient A RECT describing the area taken up by the 
client area of the window 

dwStyle The window's styles (ws *) 

dwExStyle The window's extended styles (ws EX *) 

dwWindowStatus W hether or not the window is active. 0 means 
not active. 

cxWindowBorders W idth of the window's border 

cyWindowBorders Height of the window's border 

atomWindowType Atom corresponding to the window class to 


which this window belongs 


wCreatorVersion Version that created this window 


GETWMINDOWTEXT AND 
GETMIINDOWTEXTLENGTH 
int GetWindowText ( 


HWND hWnd, // handle to window or control 
LPTSTR IpString, // text buffer 
int nMaxCount // maximum number of characters to copy 


JE 


Retrieves a copy of the window's title in 1pstring. nMaxCount Is the string length to retrieve. R eturns 
the number of characters actually read. 


int GetWindowTextLength( 
HWND hWnd // handle to window or control 
js 
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Returns the length of the window's (пипа5) title 
T hese two functions are best used together, like so: 


//retrieve the length of the window title 

int nTitleLength=GetWindowTextLength(hWndMain) ; 
//allocate a buffer to the proper size 

char* buffer=new char[nTitleLength]; 
GetWindowText(hWndMain,buffer,nTitleLength); 


SeETWINDOWTEXT 
BOOL SetWindowText ( 
HWND hWnd, // handle to window or control 


LPCTSTR lpString // title or text 


Sets the title of the specified window (hwnd) to the string supplied (1 pString). 


SYSTEM METRICS 

A system metric is a system-wide measurement usually concerning the height or width of something on 
the desktop. It also contains the existence of certain devices on the machine. 

T he function needed to retrieve one of these metrics is GetSystemMetrics. 


int GetSystemMetrics( 
int nIndex // system metric or configuration setting 
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Table 1.15 lists some of the possible птпаех values. T here are more than just this, of course, but these are 
the ones you are most likely to use with any sort of frequency. 


Table 1.15 Values for nindex 


Index Return Value 

SM_CMOUSEBUTTONS The number of mouse buttons present 
SM_CXBORDER, SM_CYBORDER The width and height of a window border 
SM_CXCURSOR, SM_CYCURSOR The width and height of a cursor 

SM_CXEDGE, SM_CYEDGE The width and height of a 3D window edge 
SM_CXSCREEN, SM_CYSCREEN The width and height of the screen 
SM_MOUSEPRESENT TRUE if the mouse is connected, or FALSE if not 
SM_SLOWMACHINE TRUE if the machine is slow, or FALSE if not 
SM_SWAPBUTTON TRUE if the user setting swaps mouse buttons, 


or FALSE if not 


SUMMARY 


W eve gone through quite a bit in this first chapter, yet we still have only scratched the surface as far 
as W IN 32 programming is concerned. | cant show you everything in just а few pages, even though I'd 
like to. 


W eve gone through basic window management, window messages, and the fundamental way W indows 
works. T hat's a lot to absorb in a single chapter. Even if you're one of those “I'll only be making full- 
screen games, anyway" folks, | ask that you consider the following: yes, most modern games are made full- 
screen— at least, the big titles are. H owever, that doesnt render this basic W IN 32 stuff useless. For exam- 
ple you'll need a regular window for some sort of configuration, or for the splash screen that commonly 
comes up whenever the CD autoruns (you know— the window with the Install, Play, Configure, and Q uit 
buttons on it?). 
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indows is a graphical operating system, with the emphasis on graphical. W indows achieves graph- 
LA ics through a subsystem called the Graphical D evice Interface (GD 1). W ith GDI, it doesnt mat- 
ter what you are drawing on— the screen, system memory, a printer, a plotter, or any other graphical 
device— because GDI does most of the work for you. 


U nfortunately, in many cases the performance of GD I isnt as good as you might want. Games are graphics 
hogs, and they cannot sacrifice speed. T hat's why DirectX was created; I'll cover it in Chapter 4, "D irectX 
at a Glance" But first | want to delve into GDI, because even when you get into using D irectX , some GD | 
will still be used, especially in the loading of bitmaps. 


RECT AND POINT 


Before getting into the objects used by GD I, we first have to explore the use of two very useful struc- 
tures— POINT and кест— and the functions that manipulate them. RECT is also used quite a bit in 
D irectD raw (discussed in Chapter 5), so this wont be the only time you'll see them. 


Before exploring the functions that deal with them, we first have to explore what ротмт and RECT 
look like. 


THE POINT STRUCTURE 


typedef struct tagPOINT { 
LONG x; 
LONG y; 

} POINT, *PPOINT; 


T he point structure isnt all that complicated. It just contains an х,у pair of integers. 


THE RECT STRUCTURE 


typedef struct _RECT { 
LONG left; 

LONG top; 

LONG right; 

LONG bottom; 

RECT, *PRECT; 


THE Можно OF GOT AND WINDOWS GRAPHICS 


RECT describes four points— (left,top), (right,top), (left,oottom) and (right,bottom).T hese four points 


represent a rectangular area. 


NOTE 


Something threw me for a while when І was first learning 
this stuff. T he inside of a RECT is where х>4ей and x«right 
and y>=top and y<bottom. In other words, the right and 
bottom edges of the RECT are not a part of the rectangle's 
interior. 

Why? I've got a few guesses. My first guess is that 
Microsoft, when it decided how RECTs worked, said that a 


pixel is between two coordinate points (for example, pixel 
(100,100) is between x=100 and x=101 and y=100 and 
y=101). My second guess is that Microsoft did this so that 
the width of a rectangle is right-left and the height is bot- 
tom-top, thus minimizing the infamous “off by one” errors. 


In either case, just keep in mind that the right and bottom 
are not in the RECT. 


RECT AND 
POINT 
FUNCTIONS 


| have these classified into three 
groups of related functions. 
Assignment functions deal with 
setting up the values of a RECT. 

O peration functions deal with 
manipulating кестѕ. Testing func- 
tions deal with getting information 
about a RECT and how something 
interacts with it. Table 2.1 lists the 
various functions | cover and the 
classification into which I've 

put them. 


Table 2.1 RECT and POINT Functions 
Function Category Use 

SetRect Assignment | Sets a ВЕСТ5 members to arbitrary values 
SetRectEmpty Assignment Sets a ВЕСТ5 members to all 05 

CopyRect Assignment X Copies one RECT'S members to another 
IntersectRect Operations Finds the common area of two RECTS 
UnionRect O perations Finds a RECT that contains both source RECTS 
OffsetRect O perations Moves a RECT by an x and y offset 
EqualRect Testing Finds if two RECTS have equal members 
IsRectEmpty Testing Checks a RECT’s members for all 05 
PtInRect Testing 


Checks whether a POINT is within the area of a RECT 
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ASSIGNMENT RECT FUNCTIONS 
Т hese functions either assign a кест5 values or copy опе RECT into another. 


SeETRECT 


BOOL SetRect( 
LPRECT lprc, // rectangle 
int xLeft, // left side 
int yTop, // top side 
int xRight, // right side 
int yBottom // bottom side 


T his returns nonzero on success or 0 on failure. Table 2.2 explains the parameter list. 


Table 2.2 SetRect Parameter List 
SetRect Parameter Purpose 


lpre Pointer to a RECT that will be filled with the values 
Supplied in the other parameters 

xLeft Value to put in the RECT'S left member 

yTop Value to put in the RECT'S top member 

xRight Value to put in the RECT'S right member 

yBottom Value to put in the RECT'S bottom member 


SetRect IS equivalent to the following code: 


//rc is a RECT 
rc.leftexLeft; 
rc.top-xTop; 
rc.rightexRight; 
rc.bottom-yBottom; 


In my opinion, doing this in a single function call is much easier to read, and | think you'll agree. 
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SETRECTEMPTY 
BOOL SetRectEmpty ( 

LPRECT 1ргс // rectangle 
); 


T his returns nonzero on success ог 0 on failure. Т he parameter 1prc is a pointer to the вест that you 
want to set to empty. An empty rect has all members equal to 0. 


SetRectEmpty 15 equivalent to this: 


//гс is a RECT 
SetRect(&rc,0,0,0,0); 


It's a good idea to set any temporary RECT variable you arent going to use for a while to empty. Following 
this practice will help minimize strange glitches. 


COPYRECT 


BOOL CopyRect( 
LPRECT lprcDst, // destination rectangle 
CONST RECT *lprcSrc // source rectangle 

); 


T his returns nonzero on success or 0 on failure. Copies the members pointed to by 1prcsrc into the 
members pointed to by 1prcbst. 


It isnt absolutely necessary to use CopyRect to set one RECT equal to another. Indeed, you could just do 
the following: 


//rcl and rc2 are RECTs 
rc2-rcl; 


Doing this does the exact same thing as CopyRect. So why dont | suggest its use? U sing CopyRect more 
accurately indicates the intended operation, and the equal sign does not. 


OPERATION RECT FUNCTIONS 
T hese functions either combine or modify кестѕ in some way. 
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OFFSETRECT 


BOOL OffsetRect( 
LPRECT lprc, // rectangle 
int dx, // horizontal offset 
int dy // vertical offset 


T his returns nonzero on success or 0 on failure T he left and right members pointed to by 1prc are 
increased by dx, and the top and bottom members are increased by dy. 


OffsetRect is equivalent to the following code: 


/1ргс is pointer to RECT 
prc->leftt=dx; 
prc->topt=dy ; 
prc->right+=dx; 
prc->bottomt=dy ; 


— m ee ун. 


FfsetRect IS quite handy when you want to have the same-sized RECT in a different location. 


© 


INTERSECTRECT 


BOOL IntersectRect ( 

LPRECT lprcDst, // intersection buffer 
CONST RECT *lprcSrcl, // first rectangle 

CONST RECT *lprcSrc2 // second rectangle 

E 


If the RECTS pointed to by 1ргс5гс1 and 1prcsrc? intersect, this function returns nonzero. If they do 
not, it returns 0. 1prcost Is filled with the intersecting вест. Figure 2.1 illustrates the output of 
IntersectRect. 
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First Source RECT 


Second Source RECT 


UNIONRECT 


BOOL UnionRect( 

ІРКЕСТ lprcDst, // destination rectangle 
CONST RECT *lprcSrcl, // first rectangle 

CONST RECT *lprcSrc2 // second rectangle 
)E- 


Figure 2.1 


IntersectRect 
(the shaded area 
marks the intersection) 


T his returns 0 if the resulting union (pointed to by 1ргс05%) is an empty вғст. It returns nonzero other- 
wise. Т he REcTS pointed to by 1prcsrci and 1prcsrc? are combined to make the smallest rect that 


could contain both, (see Figure 2.2). 


First Source RECT 


Second Source RECT 


Figure 2.2 


The shaded area shows 
the result of a call to 
UnionRect 
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TESTING RECT FUNCTIONS 


T he testing functions check the status of a RECT in relation to another вест, in relation to itself, or in 
relation to a POINT. 


EQUALRECT 


BOOL EqualRect( 

CONST RECT *lprcl, // first rectangle 
CONST RECT *lprc2 // second rectangle 
Ё 


T his returns 0 if the two rectangles (pointed to by трест and 1ргс2) are not equal, and nonzero if 
they are. 


ISRECTEMPTY 


BOOL IsRectEmpty( 
CONST RECT *lprc // rectangle 
); 


T his returns 0 if the rectangle pointed to by 1prc is not empty, and nonzero if it is empty. 


PTINRECT 

BOOL PtInRect( 
CONST RECT *lprc, // rectangle 
POINT pt // point 


Checks to see if the PoINT pt is within the вест pointed to by 1prc. T his returns nonzero if it is, and 0 
if it is not. 

Pt InRect 15 equivalent to the following code: 

//\pre is pointer to RECT 


BOOL ptinrect=((pt.x>=Iprce->left) && (pt.x«lprc-»right) && (pt.y>=Iprc->top) && 
(pt.y<lprc->bottom)); 


T here are а few more вЕСТ functions, but they arent very useful and so | didnt cover them. If you're curi- 
ous, they are called InflateRect and SubtractRect, and they can be found in M SDN. 
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ANATOMY OF A WINDOW 


As you are well aware, a window consists of more than just an area on which you can draw. Depending on 
its use, a window contains minimize and maximize buttons, a title bar, a close button, a system menu, a 
sizable or nonsizeable border, scroll bars, and so on. T he inclusion of these in your window depends on 
the style with which you create it. W indows takes care of making these look correct, so you can just con- 
cern yourself with drawing on the inside of the window. 


T he section upon which you can draw is called the dient are. T he rest of the window is the nondient аге. 
Figure 2.3 shows these two areas. W hen the client area needs repainting, you get им PAINT messages from 
W indows. 


Non-Client Area Figure 2.3 
Client and nonclient 
areas of a window 


Client Area 


NOTE 
If you want to, you can override the wayW indows draws the non- 


client area by responding to the WM_NCPAINT message. 
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GeETCLENTRECT 
Т he area contained in the client area can be retrieved with the function GetC1ientRect: 
BOOL GetClientRect( 


HWND hWnd, // handle to window 
LPRECT 1рКесї // client coordinates 


ji 
T his returns nonzero on success or 0 on failure Table 2.3 explains the parameter list. 


Table 2.3 GetClientRect Parameter List 
GetClientRect Parameter Purpose 


hWnd W indow for which you would like to retrieve the 
client area 
ТрВесї Pointer to a RECT into which the client area informa- 


tion is retrieved 


T he left and top members of the rect are 0. T he right and bottom contain the width and height. 


GeETWINDOWRECT 
T he area that contains the entire window can be retrieved with the function GetWindowRect. 
BOOL GetWindowRect ( 
HWND hWnd, // handle to window 
LPRECT 1рКесї // window coordinates 
jos 
T his returns nonzero on success or 0 on failure. Table 2.4 explains the parameter list. 


Table 2.4 GetW indowRect Parameter List 
GetW indowRect Parameter Purpose 


hWnd W indow for which you would like to retrieve the 
client area 
ТрВесї Pointer to a RECT into which the client area infor- 


mation is retrieved 
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T he coordinates returned in the кест are screen coordinates, so this function yields different results when 
the window has been moved around. 

[ «5 say that you are making a game that needs to have a play area that has certain dimensions (640х480, 
for example). You may want this application to be windowed, but it is nearly impossible to determine how 
big of a window you have to make, because user settings modify how large some types of windows are. 


So, what to do? 


ADIUSTWINDOWRECT AND 
ADIUSTWINDOWRECTEX 


Luckily, W in32 does have a couple of functions that help you in this area. T hey are AdjustWindowRect 
and AdjustWindowRectEx 


ADIJUSTWINDOWRECT 


If you used CreateWindow to create your main window (or any window you might be adjusting), you 
would use AdjustWindowRect to modify the size of your client area. 


BOOL AdjustWindowRect ( 
LPRECT IpRect, // client-rectangle structure 
DWORD dwStyle, // window styles 
BOOL bMenu // menu-present option 

)3 


T his returns nonzero on success or 0 on failure. Table 2.5 explains the parameter list. 


Table 2.5 AdjustW indowRect Parameters 
AdjustW indowRect Parameter Purpose 


lpRect Pointer to a RECT that contains the desired client 
area on entry and the desired window RECT on exit 

dwStyle Style of the window (as sent to CreateWindow) 

bMenu TRUE Or FALSE, depending on whether or not the 


window has a menu 
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ADIJUSTWIINDOWRECTEX 


If you used CreateWindowEx to create your window, use AdjustWindowRectEx to modify the size of 
your dient area. 


BOOL AdjustWindowRectEx( 


LPRECT lpRect, // client-rectangle structure 
DWORD dwStyle, // window styles 
BOOL bMenu, // menu-present option 


DWORD dwExStyle // extended window style 


T his returns nonzero on success or 0 on failure. Table 2.6 explains the parameter list. 


Table 2.6 AdjustW indowRectEx Parameters 
AdjustW indowRectEx Parameter Purpose 


ІрКес% Pointer to а RECT that contains the desired client 
area on entry and the desired window RECT on 
exit 

dwStyle Style of the window (as sent to CreateWindowEx) 

bMenu TRUE Or FALSE, depending on whether or not the 


window has a menu 


dwExStyle Extended style of the window (as sent to 
CreateWindowEx) 


T he choice of AdjustWindowRect VefSUS AdjustWindowRectEx depends solely on whether or not 
CreateWindow OF CreateWindowEx was used to create your window. 
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NOTE 


Under WIN32, there is absolutely no functional difference 
between CreateWindow and CreateWindowEx, nor is there a dif- 
ference between AdjustWindowRect and AdjustWindowRectEx. 
The CreateWindow function is not actually a function at all. It is a 
macro that calls CreateWi ndowEx and supplies the dwExStyle 
parameter with а 0.The same goes for Ad justWindowRect.It is 
always best to use the Ex version of the function. 


USING ADJUSTWNINDOWRECTEX 
Load 150Н e2 1.срр into your compiler, and take a look at the Prog_Init function: 


bool Prog Init() 

{ 
//rectangle into which we will place the desired client RECT 
RECT rc; 
SetRect(&rc,0,0,640,480); 
//get the window rect based on our style and extended style 
AdjustWindowRectEx(&rc,WS BORDER | WS SYSMENU | WS_VISIBLE,FALSE,0); 
//use movewindow to resize the window 
MoveWindow(hWndMain,O,0,rc.right-rc.left,rc.bottom-rc.top, TRUE); 
return(true);//return success 


In this function, you resize the window using MoveWindow so that you have a 640x480 client area. 


T hrough my experience with using Ad justWindowRectEx, | have found that sometimes it just doesnt 
work, depending on the combination of style and extended style flags for the window. If you want to try 
using AdjustWindowRectEx, make sure you get the client RECT size you want. If you dont, all is not lost. 
You can manually get the proper window size by using GetClientRect, GetWindowRect, and 

oveWi ndow, as shown in the following snippet of code: 


//get the client rect 

RECT rcClient; 
GetClientRect(hWndMain,&rcClient); 

//get the window rect 

RECT rcWnd; 

GetWindowRect(hWndMain, &rcWnd) ; 

//make the window rect left and top be zero 
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OffsetRect(&rcWnd,-rcWnd.left,-rcWnd.top); 

//get the difference in the width 

int iWidthDelta=rcWnd.right-rcClient.right; 

int iHeightDelta-rcWnd.bottom-rcClient.bottom; 

//set up desired client rect 

SetRect(&rcClient,0,0,640,480);//640 and 480 can be replaced with desired meas- 
urements 
//adjust the width of the desired client rect 
rcClient.right+=iWidthDelta; 
rcClient.botomt=iHeightDelta; 

//use movewindow to set desired height and width 
MoveWindow(hWnd,0,0,rcClient.right,rcClient.bottom, TRUE) ; 


U p until now this chapter has been little more than a list of functions and parameters. U nfortunately, it 
has been necessary to make it so— there аге alot of things you have to know in order to use GD I effec- 
tively. N ow that you've got the goods on ВЕСТ, POINT, and the client area, you can actually start doing 
something. 


DEVICE CONTEXTS 


W indows can draw to several different types of devices— monitors, printers, plotters, and system memory. 
D rawing to any of these devices is handled by the exact same mechanism— device contexts (D Cs). A DC 
is an abstraction of something that can be drawn upon. Some devices have varying coordinate systems. For 
example, a printer might print at 600dpi, and your screen has 72dpi. D Cs ensure that the proper transfor- 
mations (scaling, stretching) can be performed, regardless of the coordinate system used internally by the 
device T his is a good thing, because it achieves device independence, and you have to deal with only а sin- 
gle set of functions instead of a billion different APIs, each for a different device 


Of course, device independence has its cost. U sing device contexts is significantly slower than working 
directly with the hardware, since commands have to be filtered through several layers of abstraction before 
the operation is actually performed. You'll reduce this problem when you make the move to D irectX , 
which has a lower level of abstraction. (DirectX talks to hardware drivers, which is as close as you can get 
to bare metal in W indows.) 


You had slight exposure to D Cs in the preceding chapter, when you responded to the им PAINT message 
and used BeginPaint and EndPaint. 


OSTAINING DEVICE CONTEXTS 


In WM_PAINT, YOU USe BeginPaint and EndPaint to retrieve a DC, and you can then use that DC for 
drawing operations. T his is one way to go about it. Н owever, using BeginPaint and EndPaint is limited 
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to times when areas of the client area have been invalidated (for example covered up by something else, like 
another window). 


INVALIDATE RECT 
You can invalidate portions of the client area by using InvalidateRect. 
BOOL InvalidateRect( 


HWND hWnd, // handle to window 
CONST RECT *1рКесф, // rectangle coordinates 
BOOL bErase // erase state 


DE 


T his returns nonzero on success or 0 on failure. T he hwnd and 1pRect parameters should be self-explana- 
tory by now. bErase tells the application whether or not to erase the background during the next call to 
BeginPaint. 


If you really want to, you can use this method. Call InvalidateRect, and wait for the им PAINT message 
to be processed. T hat would be very W indows-friendly of you. H owever, you are a game programmer, and 
games are rarely W indows-friendly. 


GEeTDC 
M ost of the time, you'll grab a window's DC using берс. 


HDC GetDC( 
HWND hWnd // handle to window 
3 


T his takes as a parameter the window for which you want the D C, and then it returns that D C. Keep in 
mind that W indows is letting you "borrow" this D C. You have to put it back later or suffer the conse 
quences. 


RELEASEDC 
W hen you are done with the DC and it's time to give it back, you use ReleaseDC. 


int ReleaseDC( 
HWND hWnd, // handle to window 
HDC hDC // handle to DC 
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CAUTION 


If you do not сай Re1easeDC for every call to Get DC, very bad things will 
happen.You've been warned. 


So, if you want to perform some drawing operations on your main window, you do this: 


//borrow the dc from the main window 
HDC hdceGetDC(hWndMain); 

//draw stuff 

//return the dc to the system 
ReleaseDC(hWndMain,hdc); 


Memory OCs 


N ot all the DCs you'll be working with will be borrowed from a window. For example, later you'll load 
images and place them into memory DCs. A memory DC is nothing more than a bit of your computer's 
memory that behaves as though it is a device upon which you can draw. 


CREATECOMPATIBLEDC 
T he mechanism by which you will do this is CreateCompatibleDC. 


HDC CreateCompatibleDC( 
HDC hdc // handle to DC 
ys 


T his function creates a memory DC compatible with a supplied hdc and returns the created D C. If you 
pass NULL, the DC that is created is compatible with the screen. 


Әкіғте ос 
W hen you are done with a memory DC, you use DeleteDC. 


BOOL DeleteDC( 
HDC hdc // handle to DC 
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So, what is in these memory D Cs after you create them? N ot much, as it turns out. A memory DC con- 
tains а 1x1 monochrome bitmap. W hat good is that? W dll, the 1x1 bitmap isnt really good for anything. 
H owever, there has to be something in a D C. O therwise, it cant exist, and using the DCs in the functions 
that need them would cause errors. 


GD1 OBJECTS 


All this stuff about D Cs is great, but we havent actually covered what to do with them. T hat's where GDI 
objects come in. T hey arent exactly objects in the object-oriented programming sense of the word. T hey 
areW indows objects, and you reference them by way of HANDLES (I told you wed be having more of 
them). 


T here are five types of 601 objects that you need to be concerned with: НВІТМАР, HBRUSH, HPEN, HFONT, 
and HRGN: 


= An HBITMAP consists of a two-dimensional graphic. In W indows, this usually comes from a .bmp file or is 
created to given dimensions on-the-fly. 

= An HBRUSH consists of a colored fill pattern. It is used to fill in areas of арс. 

= An HPEN consists of a colored line style and width. It is used to draw primitives (lines, rectangles, ellipses) 
on aDC. 

= An HFONT consists of a set of characters. It is used to print text on a DC. 

= An HRGN represents a shape that can be used for clipping, drawing, framing, or filling. T hese regions can be 
rectangles, ellipses, polygons, or just about anything else you might imagine. 


A DC can contain exactly one of each of these at any given time T his may seem a little backwards, but it's 
not. Consider a DC a mechanical device that draws. T his machine can select a piece of paper (an 

HBITMAP) on which to draw, and it can pick a pen (нрем) with which to draw, a brush (HBRUSH) with 
which to fill areas, a typeface (нғомт) with which to stamp letters, and an artist's template (нвам) with 
which to draw shapes or draw on only a particular area. 


EELECTO)EJECT 
In order to place a given object into a D C, you use SelectObject. 


HGDIOBJ SelectObject( 
HDC hdc, // handle to DC 
HGDIOBJ hgdiobj // handle to object 
ie 


T his function places the desired GD! O bject (HBITMAP, HRGN, HFONT, HPEN, ОГ HBRUSH) into the D C, and 
it returns the GD I| object that the new object has replaced (except in the case of HRGN— see Chapter 3, 
“Fonts, Bitmaps, and Regions”). 
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CAUTION 


We're about to have another “put your toys away” moment here.W hen 
you create a GDI object, no matter what kind, you have to later destroy 
it. Technically, in W IN 32, you don't have to. W IN 32 maintains a separate 
memory space for each application, and when the application terminates, 
all of that application's resources are released. Still, it’s good program- 
ming practice to delete GDI objects when you're done with them. 


So, if you wanted to bring a white brush into a D C and clean it up later, youd do something like the 
following: 


//create solid white brush 

HBRUSH hbrNew=CreateSol idBrush(RGB(255,255,255) ); 

//select the new brush into a ас and save the old one (note the typecast of the 
return value) 
HBRUSH hbrOld=(HBRUSH)SelectObject(hdc,hbrNew) ; 
//use drawing functions that use the new brush 
//return the old brush to the dc 
SelectObject(hdc,hbrOld); 

//delete the brush we no longer need 
DeleteObject(hbrNew) ; 


T his is something of a pain, | know (bdie/e me— | know). 


PIXEL PLOTTING WITH GO! 


А pixd is a pictorial dement. It is the smallest piece of graphics that you can manipulate. Т he number of 
pixels on the screen depends on your display settings. | run my machine at 1024x768 most of the time, 
so | have over 750,000 pixels on my screen. 


Besides width and height, your screen also has color depth. Common color depths (measured in bits per 
pixel— bpp) range from 1 (which is monochrome) to 32 (true color with an extra byte). T he most com- 
mon color depths are 8, 16, 24, and 32. An 8-bit color depth requires a method of color abstraction 
known as color indirection and is handled by means of a palette | wont be covering palettes. 
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For 16, 24, and 32 bits per pixel, thereis an RGB representation for your pixels. T his means that certain 
bits represent one of the three primary colors of light— red, green, or blue. 


Pixel format will become more of a concern when you get to D irectD raw. In СОТ, you get to pretend that 
everything is 24bpp, and W indows does all the conversions for you. 


In GDI, all colors are represented by coLoRREFS. А COLORREF is merely an int. It has 8 bits for each of 
red, green, and blue. Because each is 8 bits, you can have red, green, and blue values from 0 to 255. Sincea 
COLORREF 15 24 bits, it can be scaled down to 16 bits, and in 32-bit modes, the number of bits used per 
pixel for the color is still only 24. 


THE RGB MACRO 
To assign a color to a cOLORREF, use the ков macro: 


]9ейие RGB(r,g,b) 
((COLORREF)(( (BYTE) Cr) | (CWORD) ( (BYTE) (9) )<<8)) | CCCDWORD) (BYTE) (р) )<<16))) 


Р1хЕ MANIPULATION FUNCTIONS 
Essentially, there are three of these: setPixe!, SetPixelV, and GetPixel. 


EETTUXEL 

COLORREF SetPixel( 
HDC hdc, // handle to DC 
int X, // x-coordinate of pixel 
int Y, // y-coordinate of pixel 


COLORREF crColor // pixel color 
); 


SetPixel needs ап нос, an X,Y position, and a coLorrer. It does its best to plot the pixel to the given 
HDC. T he return value contains the actual color that was plotted. 


SETPIXELV 

BOOL SetPixelV( 
HDC hdc, // handle to device context 
int X, // x-coordinate of pixel 
int Y, // y-coordinate of pixel 


COLORREF crColor // new pixel color 
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Like SetPixel, SetPixelv needs an нос, an X,Y position, and a coLonner. Unlike setPixe1, this func- 
tion does not return the color plotted. It returns 0 on failure or nonzero on success. 


GEeETT1xEL 


COLORREF GetPixel( 
HDC hdc, // handle to DC 
int nXPos, // x-coordinate of pixel 
int nYPos // y-coordinate of pixel 


GetPixel needs an нос and an X,Y position. It returns the color of that position on the specified нос. 


A PIXEL PLOTTING EXAMPLE 
№ ow that you can finally draw something (it's about time, | know), let's do so. Load up ISoH ex2_2.cpp. 
T he only difference between this program and IsoH ex1 1.cpp is an added case іп the window procedure: 


//the mouse moved 
case WM_MOUSEMOVE: 
{ 
//if the left button is down 
if(wParam & MK_LBUTTON) 
{ 
//extract x and y from Трагат 
int x-LOWORD(lParam); 
int y=HIWORD(1Param); 


//borrow the dc from the main window 
HDC hdceGetDC(hWndMain); 


//plot the pixel 
SetPixelV(hdc,x,y, RGB(255,255,255)); 


//return the dc to the system 
ReleaseDC(hWndMain,hdc); 


//handled, so return 0 
return(0); 
break; 
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In this little stretch of code, you respond to the им_моизЕмо\Е message. First, you check to see if the left 
button is down. If it is, you borrow the DC from the main window, plot the pixel, and release the D C 
back to the system. W ith this relatively small change, you can now draw. Figure 2.4 demonstrates my lack 
of artistic ability. 


ЕЕ IsoHex 2-2 Е Pigre 24 


Pixel-plotting demo 


OK, so it isnt Paint Shop Pro. H eck, it isnt even M icrosoft Paint. But it is a step in the right direction, 
and that’s all that counts. 


NOTE 
I'd like to point out something about this particular application, 
because it applies to most of the applications in the early part of this 


book. If you bring another application’s window in front of it, and then 
bring it back in front, the part of the overlap will be erased. You'll read 
more about fixing this later. 
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USING PENS 


Pixels are great, but dealing with just pixels for everything would become a nightmare, and game program- 
ming would stop being fun. 


So, to draw lines and shapes and so on, you'll use HPENS and functions that use the pens in a DC. 


CREATEPEN 
Creating a pen is simple. T he function that does so is named, of all things, CreatePen. 


HPEN CreatePen( 
int fnPenStyle, // pen style 
int nWidth, // pen width 
COLORREF crColor // pen color 
Ms 


T his function returns a handle to a pen with the desired style width, and color. Table 2.7 explains the 
parameter list. 


Table 2.7 CreatePen Parameters 
CreatePen Parameter Purpose 


fnPenStyle The style of the pen (see the paragraph after this table) 
nWidth Desired width of the pen 
crColor Desired color of the pen 


T he fnPenStyle parameter can have a number of values: 


= PS SOLID А Solid pen. М ay have any width. 

= PS DASH A dashed pen. М ust have a width of 0 or 1. 

= PS DOT A dotted pen. M ust have a width of 0 or 1. 

= PS DASHDOT A dash dot pen. M ust have a width of 0 or 1. 

= PS DASHDOTDOT A dash dot dot pen. M ust have a width of 0 or 1. 
= PS NULL An invisible pen 


To use a pen, you simply select it into a device context using SelectObject, and youre ready to go. 
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DRAWING FUNCTIONS 


Before we get to drawing functions themselves, let's take a moment to talk about the current position with- 
in aDC. 


Internally, a DC maintains a current position. T he current position is 
similar to a cursor in a way. It keeps track of where you left off when 
drawing. (In this way, you can draw continuous shapes without modify- 
ing more than one line of code) 


You can set or get the current position (CP) with the following two 
functions. 


MoveToEx 

BOOL MoveToEx( 
HDC hdc, // handle to device context 
int X, // x-coordinate of new current position 
int Y, // y-coordinate of new current position 


LPPOINT lpPoint // old current position 
у 


T his returns nonzero on success and 0 on failure Table 2.8 explains the parameter list. 


Table 2.8 MoveToEx Parameters 
MoveToEx Parameter Purpose 


һас Handle to the device context for which you are setting the CP 
Xa Y The desired position of the CP 
lpPoint A pointer to a POINT.The former CP is placed here. 


GETCURRENTPOSITIONEX 


BOOL GetCurrentPositionEx( 
HDC hdc, // handle to device context 
LPPOINT IpPoint // current position 

Уз 


T his returns nonzero on success or 0 on failure. Table 2.9 explains the parameter list. 
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Table 2.9 GetCurrentPositionEx Parameters 
GetCurrentPositionEx Parameter Purpose 


hdc Handle to the device context for which you are 
getting the CP 

lpPoint Pointer to a POINT structure that will be filled with 
the CP 


ОК, so you can get and set the CP. So what? Seems sort of useless. 


LiNETO 
Introducing the LineTo function. LineTo draws a line in the current pen from the CP to a specified point. 


BOOL LineTo( 
HDC hdc, // device context handle 
int nXEnd, // x-coordinate of ending point 
int nYEnd // y-coordinate of ending point 
ys 


T his returns nonzero on success or 0 on failure. It moves the CP to пхЕпа, пуЕпа in the given hdc. It 
draws a line as it does so. 


A ілме DRAWING EXAMPLE 
Since we have a new toy (LineTo), let's play. Load up 150Н ex2_3.cpp. 


T his program is similar to 150Н ex2_2.cpp, but it gets a little more involved. First, you have to create a pen 
and select it into your window's D C, so you declare two global variables, npenNew and һреп014. 


H eres the Prog_Init function: 


bool Prog_Init() 

{ 
//create the new pen 
hpenNew=CreatePen(PS_SOLID,0,RGB(255,255,255)); 
//borrow dc from main window 
HDC hdc=GetDC(hWndMain) ; 
//select new pen into dc 
hpenOld=(HPEN)SelectObject(hdc,hpenNew) ; 
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//release ас to system 
ReleaseDC(hWndMain,hdc); 
return(true);//return success 


H ere you take care of creating the new pen (it's white) and putting it into the DC. 
N ow, here's Prog Done, on the other end of the program: 


void Prog Done() 

{ 
//borrow ас from main window 
HDC hdceGetDC(hWndMain); 
//restore old pen to dc 
SelectObject(hdc,hpenOld); 
//release dc to system 
ReleaseDC(hWndMain, hdc); 
//delete new pen 
DeleteObject (hpenNew) ; 


Н ere you restore the old pen to the DC and delete the pen you created— you put your toys away after you 
are done playing with them. 


N ow that the pen is set up, you can take care of doing the real work. T he main work in this case is done 
in two window message handlers, wM_MOUSEMOVE and WM_LBUTTONDOWN, 


case WM LBUTTONDOWMN: 
{ 


//extract x and у from lparam 
int x=LOWORD(1Param); 
int y=HIWORD(1Param); 
//borrow the main window’s DC 
HDC hdc=GetDC(hWndMain) ; 
//update the CP 
MoveToEx(hdc,x,y,NULL); 
//return the dc to the system 
ReleaseDC(hWndMain,hdc); 
//handled, return O 
return(0); 

}break; 


ЕСЕВ ISOMETRIC GAME PROGRAMMING ulrH DIRECTX 7,0 


In this handler, you must update the CP of the window's DC because if you just responded to movements 
of the mouse, you would get errors. (Try commenting out the моуетоЕх line, and see what | mean.) 


case WM_MOUSEMOVE: 
{ 


//if left button is down 

if(wParam & MK_LBUTTON) 

{ 
//extract x and y from Трагат 
int x=LOWORD(1Param) ; 
int y=HIWORD(1Param) ; 


//borrow the main window’s DC 
HDC hdc=GetDC(hWndMain) ; 


//line to the x,y position 
LineTo(hdc,x,y); 


//return the ас to the system 
ReleaseDC(hWndMain,hdc); 


//handled, return 0 
return(0); 
ibreak; 


W hen the mouse is moved, and the left button is down, you draw a line to the mouses position. D oing so 
updates the CP. 


T he resulting program doesnt do too much more than what IsoH ex2 2 did, except that it isnt so... well, 
pixelated. Figure 2.5 shows the application's output. 
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— 
Once again, an artist | 
am not 
NOTE Play around with IsoH ex2_3 a bit, changing the pen style and line 
This program suffers width and color so that you can see the various effects that can be 
from the same erasure created. After you're done, we'll move on to brushes. 


problem that 2_2 did. 


BRUSHES 


In GDI, you use pens to draw, and you use brushes to fill. You can create brushes using a number of func- 
tions. Т he functions I'm going to cover here are the most commonly used: Createso1idBrush and 
CreateHatchBrush. 


BRUSH CREATION 


HBRUSH CreateSolidBrush( 
COLORREF crColor // brush color value 
у 
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CreateSolidBrush takes a color and returns a brush in that color. 


HBRUSH CreateHatchBrush( 
int fnStyle, // hatch style 
COLORREF clrref // foreground color 


CreateHatchBrush takes a style and a color and returns a brush with that color and style. H atch brush 
styles are represented by Н 5 * constants like the following: 


= HS BDIAGONAL A 45-degree stripe that runs downward from left to right 
= HS CROSS A combination of horizontal and vertical stripes 

" HS DIACROSS A combination of the two diagonal stripes 

= HS FDIAGONAL A 45-degree stripe that runs upward from left to right 

и HS HORIZONTAL Н orizontal stripes 

= HS VERTICAL Vertical stripes 


To bring a brush into а device context, use Select Object just like you do with pens. Always be sure to 
restore the old brush when you are done. U se Deletedbject to destroy brushes. 


EXTFLOODFILL 
To fill in a given area, use Ext FloodFill. 
BOOL ExtFloodFill( 


HDC hdc, // handle to DC 
int nXStart, // starting x-coordinate 
int nYStart, // starting y-coordinate 


COLORREF crColor, // fill color 
UINT fuFillType // fill type 


T his returns nonzero on success or 0 on failure Table 2.10 explains the parameter list. 
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Table 2.10 ExtFloodFill Parameters 
ExtFloodFill Parameter Purpose 


hdc Handle to a device context in which you would like the 
fill to occur 

nXStart,nYStart The coordinate at which to begin the fill 

ercolor Depending on fuFillType, either the color at which to 


stop filling, or the color to fill over 


fuFillStyle Either the value FLOODFILLBORDER Or FLOODFILLSUR- 
FACE. FLOODFILLBORDER fills until crColor is reached, 
and FLOODFILLSURFACE fills over any adjacent areas that 
are the same color as crColor. 


A BRUSH EXAMPLE 


So, another example. Load ир 150Н ех2 4.cpp. IsoH ex2. 4.cpp is mostly just 150Н ех2 3.cpp with an extra 
message handler, wM_RBUTTONDOWN. 


case WM RBUTTONDOWMN: 
{ 


//extract x and у from lparam 

int x=LOWORD(1Param) ; 

int y=HIWORD(1Param); 

//borrow the main window’s DC 

HDC hdc=GetDC(hWndMain) ; 

//line to the x,y position 

ExtFloodFill(hdc,x,y,RGB(255,255,255) , FLOODFILLBORDER) ; 
//return the dc to the syste 

ReleaseDC(hWndMain,hdc); 


}break; 


Figure 2.6 shows the output of this sample program. 
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Ен IsoHex 2-4 Figure 2.6 
These are clouds. 


No, really. 


In this app, you still draw lines with the left mouse button, and fill areas with the right. 


FILLING 1N RECTANGULAR AREAS 


Possibly the most common brush operation you are likely to do is filling a rectangular area. T his operation 
is done with the ri11Rect function. 


int FillRect( 


HDC hDC, // handle to DC 
CONST RECT *lprc, // rectangle 
HBRUSH hbr // handle to brush 


); 
On failure, this returns 0. О n success, it returns nonzero. Table 2.11 explains the parameter list. 


Table 2.11 FillRect Parameters 
FillRect Parameter Purpose 


hDC Handle to the device context for which you would like a rectangu- 
lar area filled 

lore A pointer to a rectangle describing the area you would like filled 

hbr The brush with which you would like the rectangular area of the 


DC filled 
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If you wanted, for example, to clear out the entire client area, this is what you would do: 


//borrow ас from main window 

HDC hdc=GetDC(hWndMain); 

//set up rect to contain entire client area 

RECT rc; 

GetClientRect(&rc); 

//fill in given rectangle with black brush 
FillRect(hdc,&rc, (HBRUSH)GetStockObject(BLACK_BRUSH) ); 
//return ас to system 

ReleaseDC(hWndMain,hdc); 


PENS AND BRUSHES TOGETHER: 
SHAPE FUNCTIONS 
N ow, being able to draw lines is great, and filling in bordered areas and rectangles is cool, too. Н owever, in 


order to be a fully functional АРІ, you have to have other primitives— circles, rectangles, polygons. GD I 
has these and more. I’m only going to cover Ellipse, Rectangle, RoundRect, and Polygon. 


With all of these shapes, 601 outlines the shape with the current pen and fills it with the current brush. 


ELLIPSE 

BOOL Ellipse( 
HDC hdc, // handle to DC 
int nLeftRect, // x-coord of upper-left corner of rectangle 
int nTopRect, // y-coord of upper-left corner of rectangle 


int nRightRect, // x-coord of lower-right corner of rectangle 
int nBottomRect // y-coord of lower-right corner of rectangle 
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T his returns nonzero on success or 0 on failure Table 2.12 explains the parameter list. 


Table 212 Ellipse Parameters 


Ellipse Parameter Purpose 

hdc The hdc on which you want the ellipse to be drawn 
nLeftRect The left of the rectangle that bounds this ellipse 
nTopRect The top of the rectangle that bounds this ellipse 
nRightRect The right of the rectangle that bounds this ellipse 
nBottonRect The bottom of the rectangle that bounds this ellipse 


W ith other graphical APIs, drawing an ellipse is done by specifying the center and then the x and y radii. 
In GDI, however, it is done by supplying the rectangle that bounds the ellipse. 


NOTE 

The center of the ellipse is at x=(nLeftRect+nRightRect)/2 and 
y=(nTopRect+nBottomRect ) /2.The horizontal (x) radius is 
abs(nRightRect-nLeftRect)/2,and the vertical (y) radius is 


abs(nBottomRect-nTopRect)/2.The abs isin there because as 
far aSE11ipse is concerned, nLeftRect does not have to be less 
than nRightRect, and nTopRect does not have to be less than 
nBottomRect. 


RECTANGLE 

BOOL Rectangle( 
HDC hdc, // handle to DC 
int nLeftRect, // x-coord of upper-left corner of rectangle 
int nTopRect, // y-coord of upper-left corner of rectangle 


int 
int 


nRightRect, // x-coord of lower-right corner of rectangle 
nBottomRect // y-coord of lower-right corner of rectangle 
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T his returns nonzero on success or 0 on failure. Table 2.13 explains the parameter list. 


Table 2.13 Rectangle Parameters 
Rectangle Parameter Purpose 


hdc 


nLeftRect 


nTopRect 


nRightRect 


nBottomRect 


The hdc on which you would like this rectangle drawn 
The left of the rectangle 

The top of the rectangle 

The right of the rectangle 

The bottom of the rectangle 


Rectangle has the exact same parameters as E11 ipse, only instead of drawing the ellipse bound by a rec- 
tangle, it draws and fills the rectangle. 


ROUNDRECT 
BOOL RoundRect( 


HDC 
int 
int 
int 
int 
int 
int 


os Ss ажа” 2 


ас, 
LeftRect, 
TopRect, 
RightRect, 
BottomRect, 
Width, 
Height 


// handle to DC 

// x-coord of upper-left corner of rectangle 
// y-coord of upper-left corner of rectangle 
// x-coord of lower-right corner of rectangle 
// y-coord of lower-right corner of rectangle 
// width of ellipse 

// height of ellipse 
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T his returns nonzero on success or 0 on failure Table 2.14 explains the parameter list. 


Table 2.14 RoundRect Parameters 
RoundRect Parameter Purpose 


dc The hdc on which you would like this rounded rectangle drawn 
LeftRect The left of the rounded rectangle 
TopRect The top of the rounded rectangle 
RightRect The right of the rounded rectangle 
BottomRect The bottom of the rounded rectangle 
idth The width of the ellipse used for rounding the corners 
Height The height of the ellipse used for rounding the corners 


| think that the RoundRect function is kind of cool. It can be used not only to draw rounded rectangles, 
but also plain rectangles (when nwidth and nHeight are both 0) or ellipses (when nwidth and nHeight 
equal the width and height of the rectangle itself). 


POLYGON 
BOOL Polygon( 
HDC hdc, // handle to DC 
CONST POINT *lpPoints, // polygon vertices 
int nCount // count of polygon vertices 


js 


T his returns nonzero on success or 0 on failure Table 2.15 explains the parameter list. 


Table 2.15 Polygon Parameters 
Polygon Parameter Purpose 


Hdc The hdc on which you want the polygon drawn 


LpPoints A pointer to an array of POINTS, containing the vertices 
of the polygon 


nCount The number of points pointed to by 1pPoints 
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For the rest of your shape-drawing needs, you have Polygon. 1pPoints must point to at least two vertices. 
T he polygon drawn will automatically be closed (a line is drawn from the last point to the first point). 


T he manner in which your polygon is filled depends on two things. T he first is whether you have any of 
the line segments of the polygon crossing, and the second is the polygon fill mode that you set for the hdc 
in question. 


POLYGON FILL MODES 
You can manipulate the polygon fill mode with SetPolyFil1Mode and retrieve it with GetPolyFil1Mode. 


FSeETPOLYFILLIYNODE 


int SetPolyFillMode( 
HDC hdc, // handle to device context 
int iPolyFillMode // polygon fill mode 

E 


T his returns the previous fill mode for the given nac and sets the new fill mode to iPo1yFi11Mode. 


GETPOLYFILLIYIODE 
int GetPolyFillMode( 

HDC hdc // handle to device context 
J; 


T his returns the current fill mode for the given nac. 


T here are two polygon fill modes— ALTERNATE and WINDING. Instead of explaining what they each mean 
(it's a confusing explanation), I'll just show you. Figure 2.7 illustrates the ALTERNATE polygon fill mode. 


ISOMETRIC GAME PROGRAMMING wItTH, DIRECTX 7,0 


Figure 2.7 


ALTERNATE 
PolyFillMode 


ALTERNATE 


In the ALTERNATE fill mode, a given pixel is filled if a horizontal line is sent in the positive x direction (to 
the right, that is) and if the number of line crossings is odd (1, 3, 5, and so on). If the number of cross- 
ings is even (0, 2, 4, and so on), no filling is done. | told you it was confusing. Figure 2.8 illustrates the 
WINDING fill mode. 


Figure 2.8 


WINDING 
PolyFillMode 


WINDING 


In the WINDING fill mode, a region is filled if it has а nonzero winding value. W hat the heck is a winding 
value, you ask? L ets see what M SDN Online (January 2000 edition) has to say about it: "T his value is 
defined as the number of times a pen used to draw the polygon would go around the region. T he direction 
of each edge of the polygon is important.” 
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Confused? M e too. U sing the итмотмо polygon fill mode seems to fill in all of the nooks and crannies of 
a polygon, so let's just leave it at that. 


SUMMARY 


T his chapter inundated you with basic GD l; по, | wont pay for any therapy you may now need. W еме 
gone through everything from W indows anatomy to graphical primitives. M uch of this you wont be using 
too much, but it's good to know. T he information you will be using from this chapter mainly consists of 
the ВЕСТ and отит stuff, some of the brush stuff, and the device context stuff. 

M ost of what I've talked about so far has been listing functions and parameters. T his will continue 
through at least the rest of this part of the book. U nfortunately, what I'm talking about requires a lot of 
knowledge, and I'm trying to get you just the important bits so that you can move on to the good stuff. 
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1 n the preceding chapter, we explored the basic use of GDI— namely, device contexts, pens, and brush- 
es. T his chapter builds on your knowledge of D Cs, exploring the topics of fonts, bitmaps (including 
icons and cursors), and regions. 


WORKING WITH FONTS 


You know what a font is (at least, | hope you do). A font is a typeface, usually containing the alphabet, the 
numbers, and punctuation, but sometimes containing graphical characters (like the various wingding 
fonts). Various fonts are shown in Figure 3.1. 


As aW indows programmer, you have the power to make use of any font installed on the system. T here are 
even tools that allow you to create your own fonts. T he key phrase is "any font installed on the system.” If 

you devdop your game to use some strange font that exists on only a few machines, you have to make sure 
you install the font as part of the installation for your game. 


H owever, you may not want to require that a font be added to a user's machine— doing so makes the font 
available for use with other applications, but it also burdens your user's computer unnecessarily. If you were 
writing a word processing utility it would be appropriate, but you're writing game! So, when you want a 
font, you'll load it temporarily and unload it later. 


ADDFONTRESOURCE 
Loading а font temporarily into the system font table is pretty easy. You use AddFontResource: 


int AddFontResource( 
LPCTSTR lpszFilename, // font file name 
ys 
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On failure this function returns 0. O n success, it returns the number of fonts added. Its parameter is 
described in Table 3.1. 


Table 3.1 AddFontResource Parameter 
AddFontResource Parameter Purpose 


lpszFilename A string containing the file name from which to load 
the font into the system font table 


W hen you are done with that font, you remove it from the system by using RemoveFontResource. 


REMNOVEFONTRESOURCE 


BOOL RemoveFontResource( 
LPCTSTR IpFileName, // name of font file 


T his returns nonzero on success or 0 on failure. T his function has the exact same parameter list as 
AddFontResource 


CREATEFONT 
О псе you have a font resource loaded, you can create a font (нғомт) by using CreateFont. 
HFONT CreateFont( 


int nHeight, // height of font 

int nWidth, // average character width 
int nEscapement, // angle of escapement 

int nOrientation, // baseline orientation angle 
int fnWeight, // font weight 


DWORD fdwItalic, // italic attribute option 
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DWORD fdwUnderline, // underline attribute option 
DWORD fdwStrikeOut, // strikeout attribute option 
DWORD fdwCharSet, // character set identifier 
DWORD fdwOutputPrecision, // output precision 

DWORD fdwClipPrecision, // clipping precision 

DWORD fdwQuality, // output quality 

DWORD fdwPitchAndFamily, // pitch and family 

LPCTSTR lpszFace // typeface name 


Scared yet?Y es, this function is along one. Luckily, you usually wont need to worry about many of the 
parameters. M ost of then are concerned with localization, and in those fields, you'll just pick whatever the 
default value is. 


CreateFont returns an HFONT that is the closest match to what is described by all of the parameters. For 
the most part, the default value for these parameters is 0. Table 3.2 explains the parameter list. 


Table 3.2 CreateFont Parameters 
CreateFont Parameter Purpose 


Height The desired average height of the font, in logical units 
Width The desired average width of the font, in logical units 
Escapement The angle at which the font is to be drawn, in tenths 
of a degree 
Orientation The angle at which the font's characters are to be drawn, 
in tenths of a degree 
fnWeight The boldness of the font 
fdwitalic TRUE for italic, FALSE for nonitalic 
fdwUnderline TRUE for underline, FALSE for nonunderline 
fdwStrikeOut TRUE for strikeout, FALSE for nonstrikeout 
fdwCharSet The type of character set you want 
FdwOutputPrecision The desired precision 
fdwQuality The desired quality 
FdwPitchAndFamily The family of the font and the pitch of the font 
lpszFace The typeface to use 
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CreateFont has lots of parameters, and most of them are used only when localization is an issue. 
(Localization is а vast topic, and I'm not going to explore it here. Just be aware that making your games 
easy to localize is а good idea, because people from many countries may want to play, and you cant always 
assume that they speak your language) 


With the exception of nHeight and 1pszFace, you can get away with using all 05 in your calls to 
CreateFont. 0 loads the default font. 


NOTE 


You may have noticed that many of the You can specify any value for nHeight. Inside 
CreateFont parameters speak of “logical GDI is a font mapper, and it will try its hardest 
units.” In all of your cases, a logical unit is to find a font that matches the height you 


one pixel, because you use a mapping mode ask for. Putting 0 in nHeight loads the 
called ММ ТЕХТ.Тһеге is more than just this default height. 


one mapping mode.T his is yet another part . 

of GDI’s device independence.You can specify 5935 the name of the font. If, for exam- 
arbitrary mapping modes for different ple you wanted to useTahoma, it would 
devices This is just an FYI. If you're curious Contain Tahoma. 

about mapping modes, read about the 

SetMapMode function in the help files. 


OUTPUTTING WITH FONTS 


In order to use а font in a given DC, you first have to bring it into the DC using SelectObject, which 
should be nothing new to you. Again, be sure to save the old font to restore it later. Also, when you are 
finished with a font (usually at the termination of а program), be sure to destroy it with а call to 
DeleteObject. 


N ext, you have to select a background mode and a text color. You do this with the setBkMode and 
SetTextColor functions. 


SGETRKKMODE 
int SetBkMode( 
HDC hdc, // handle to DC 


int iBkMode // background mode 
93 


On failure, this function returns 0. О n success, it returns the previous background mode. 
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T he nac parameter is (of course) а handle to a device context for which you are setting the background 
mode. iBkMode is the new background mode, and it is either TRANSPARENT ОГ OPAQUE.T his is almost 
unnecessary to say, but TRANSPARENT will not write in the background color, and opaque will. 


SeETrTTEXTCOLOR 


COLORREF SetTextColor( 
HDC hdc, // handle to DC 
COLORREF crColor // text color 


T his returns the previous text color or сів 1NvALID on failure. (In this case, returning 0 would be a valid 
color.) 


T he nac parameter is the handle to the device context for which you are setting the text color, and 
crColor [5 the color itself. 


TexrTOuT 
Finally, to actually get text on the screen, you usethe rextout function. 


BOOL TextOut( 


HDC hdc, // handle to DC 

int nXStart, // x-coordinate of starting position 
int nYStart, // y-coordinate of starting position 
LPCTSTR lpString, // character string 

int cbString // number of characters 


T his returns 0 on failure or nonzero on success. Table 3.3 explains the parameter list. 


Table 3.3 TextOut Parameters 
TextOut Parameter Purpose 


һас The handle to the device context on which you want to 
write characters 


nXStart,nYStart The x,y location for the start of the string 
lpString The text string to write 
cbString The number of characters to write 


A TEXTOUT EXAMPLE 


Let's do a little example. Load up IsoH ex3 1.cpp, and be sure that Paganini.ttf is in the same folder as the 
project's workspace. 
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ISOH ex3_ 1cpp is a modification of 150Н ех1 1.срр.Т he main differences are two extra global variables 
and a modified Prog_Init and Prog_Done. 


HFONT 
HFONT 


hfntNew=NULL;//paganini font 
hfntOld=NULL;//store old font 


bool Prog_Init() 


{ 


//add the paganini font to the system table 
AddFontResource("Paganini.ttf"); 


//create a font that uses paganini 
hfntNew-CreateFont(-40,0,0,0,0,0,0,0,0,0,0,0,0, "Paganini ") ; 


//borrow dc from main window 
HDC hdceGetDC(hWndMain); 


//select new font into dc 
hfntOld-(HFONT)SelectObject(hdc,hfntNew) ; 


//set background mode to transparent 
SetBkMode(hdc, TRANSPARENT) ; 


//set text color to blue 
SetTextColor(hdc,RGB(0,0,255)); 


//write text to dc 
TextOut(hdc,0,0,"Paganini",strlen("Paganini")); 


//release dc to system 
ReleaseDC(hWndMain,hdc); 
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return(true);//return success 


void Prog_Done() 

{ 
//borrow main window dc 
HDC hdc=GetDC(hWndMain); 


//restore original font 
SelectObject(hdc, hfnt0ld); 


//delete the new font 
DeleteObject(hfntNew); 


//return dc to system 
ReleaseDC(hWndMain,hdc); 


//remove the paganini font 
RemoveFontResource("Paganini.ttf"); 


T heoutput looks like Figure 3.1. 


Figure 3.1 
TextOut 
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As you can see, the modifications are relatively minor. You just 


added some font-loading stuff and output the text to the NOTE 

Windows DC. TextOut, while useful, isn't 
Таке a few moments with |soH ex3 1.срр, and play with very good at formatting 
SetBkMode, SetTextColor, and the parameters for CreateFont. text. | usually use it to dis- 
You might even go find a font somewhere and plug it into the pro- play diagnostic information 
gram to see how it looks. on-screen, like the mouse 


iti the frame rate. 
And that's the shortest way to get a font on the screen. eS Oye ваце 


DRAWTEXT 
То do any real sort of application of fonts, you'll want to use DrawText. 


int DrawText( 


HDC ПОС, // handle to DC 

LPCTSTR IpString, // text to draw 

int nCount, // text length 

LPRECT lpRect, // formatting dimensions 
UINT uFormat // text-drawing options 


2 


T his usually returns the height of the text outputted, but it might differ depending on the uFormat 
parameter (seeT able 3.5). Table 3.4 explains the parameter list. 


Table 3.4 DrawText Parameters 
DrawText Parameter Purpose 


hDC The destination device context 
lpString The string of characters that you want to display 
nCount The number of characters to display. Can be -1 to detect the 


size of the string. In this case, 1 pString must be a null-termi- 
nated string. 


ІрКес% А pointer to the bounding RECT 
uFormat The format in which to show the text (see Table 3.5) 
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M ost of these parameters match those of TextOut, except that positioning information is in 1pRect and 
formatting options are in uFormat, as shown in Table 3.5. 


Table 3.5 uFormat Values 
uFormat Value Meaning 


DT BOTTO Justifies text to the bottom of the rectangle. Must be used with 
DT SINGLELINE. 

DT CENTER Centers the text horizontally 

DT_LEFT Aligns text to the left 

DT_NOCLIP Does not perform clipping 

DT_RIGHT Aligns text to the right 

DT_SINGLELINE Displays the text on a single line only 

DT_TOP Justifies text to the top of the rectangle 

DT_VCENTER Centers text vertically. Use with DT_SINGLELINE. 


T his list is by no means exhaustive. T hese are just the most commonly used formatting options. 


A DRAWTEXT EXAMPLE 


Another sample program? Sure, why not! |soH ex3. 2.cpp (which is just a slightly modified 
IsoH ex3_ 1.срр) makes use of DrawText.T he differences lie totally in Prog Init. 


{ 
//retrieve the client rectangle 
ВЕСТ rcClient; 
GetClientRect(hWndMain,&rcClient); 
//add the paganini font to the system table 
AddFontResource("Paganini.ttf"); 
//create a font that uses paganini 
hfntNew=CreateFont(-40,0,0,0,0,0,0,0,0,0,0,0,0,"Paganini"); 
//borrow dc from main window 
HDC hdc=GetDC(hWndMain) ; 
//select new font into ас 
hfntOld-(HFONT)SelectObject(hdc,hfntNew); 
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//set background mode to transparent 
SetBkMode(hdc, TRANSPARENT) ; 

//set text color to blue 
SetTextColor(hdc,RGB(0,0,255)); 
//write text to dc 
DrawText(hdc,"Paganini",-l,&rcClient,DT CENTER | DT VCENTER | DT SINGLE- 


LINE); 


//release dc to system 
ReleaseDC(hWndMain,hdc); 
return(true);//return success 


Figure 3.2 shows what it looks like. 


Figure 3.2 


DrawText demo 


Again, play with 150Н ex3 2.cpp using different combinations of the various pr. * constants and different 
ВЕСТ, T hereis alot of power in the GDI font system, and you'll be making use of it later in 
DirectDraw. U nfortunatdy, it's slower than a custom system you could design specifically for a game. If 
you want to further explore fonts, theres plenty of information about them in M SDN Online 
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CREATING AND USING REGIONS 


A region isa GDI object, just like a pen, brush, or font. Regions are very powerful and flexible tools with 
which to accomplish things that would otherwise be very difficult. H owever, because they are slow, they are 
practically ignored. 


A region is nothing more than a shape— a rectangle, rounded rectangle, ellipse, polygon, or multiple poly- 

gons. You can do a number of things with a region. You can fill it (Fi11Rgn), frame it (FrameRgn), or dip 
with it (by selecting it into a device context). You can use it to test whether or not a point is within a given 
nonrectangular shape. 


CREATING REGIONS 


Regions, like any other 601 objects, are manipulated through the use of handles. In this case, the handle is 
HRGN. Table 3.6 lists several different types of regions and several different functions that create them. 


Table 3.6 Region Creation Functions 


Function Type of Region Created 
CreateEllipticRgn An elliptical region 
CreatePolygonRgn A polygonal region 
CreateRectRgn A rectangular region 


CreateRoundRectRgn А rounded rectangular region 


M ost of these region creation functions mirror similar shape functions that use pens and brushes (minus 
the нос parameter, of course). 


CREATEELLIPTICRGN 


НКСМ CreateEllipticRgn( 
int nLeftRect, // x-coord of upper-left corner of rectangle 
int nTopRect, // y-coord of upper-left corner of rectangle 
int nRightRect, // x-coord of lower-right corner of rectangle 
int nBottomRect // y-coord of lower-right corner of rectangle 
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CreateEllipticRgn returns а handle to an elliptical region. Table 3.7 explains the parameter list. 


Table 3.7 CreateEllipticRgn Parameters 


CreateEllipticRgn Parameter Purpose 


nLeftRect The left x-coordinate of the bounding rectangle for 
the elliptical region 


nTopRect The top y-coordinate of the bounding rectangle for 
the elliptical region 


nRightRect The right x-coordinate of the bounding rectangle for 
the elliptical region 


nBottomRect The bottom y-coordinate of the bounding rectangle 
for the elliptical region 


CREATEPOLYGONRGN 


HRGN CreatePolygonRgn( 
CONST POINT *1ррї, // array of points 
int cPoints, // number of points in array 
int fnPolyFillMode // polygon-filling mode 

2 


CreatePolygonRgn returns a handle to a polygon region. Table 3.8 explains the parameter list. 


Table 3.8 CreatePolygonRgn Parameters 
CreatePolygonRgn Parameter Purpose 


Іррі А pointer to an array of POINTS that contains the 
vertices of the polygon 

cPoints The number of points that are pointed to by 1ppt 

fnPolyFillMode Either ALTERNATE Or WINDING. Specifies the desired 


fill mode. 
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CREATERECTRGN 


HRGN CreateRectRgn( 
int nLeftRect, // x-coordinate of upper-left corner 
int nTopRect, // y-coordinate of upper-left corner 
int nRightRect, // x-coordinate of lower-right corner 
int nBottomRect // y-coordinate of lower-right corner 


T his returns a handle to a rectangular region. Table 3.9 explains the parameter list. 


Table 3.9 CreateRectRgn Parameters 
CreateRectRgn Parameter Purpose 


nLeftRect The left x-coordinate of the rectangle 
nTopRect The top y-coordinate of the rectangle 
nRightRect The right x-coordinate of the rectangle 
nBottomRect The bottom y-coordinate of the rectangle 


CREATEROUNDRECTRGN 
HRGN CreateRoundRectRgn( 


int nLeftRect, // x-coordinate of upper-left corner 
int nTopRect, // y-coordinate of upper-left corner 
int nRightRect, // x-coordinate of lower-right corner 
int nBottomRect, // y-coordinate of lower-right corner 


int nWidthEllipse, // height of ellipse 
int nHeightEllipse // width of ellipse 


FONTS, BITMAPS, AND REGIONS | BE | 


T his returns a handle to a rounded rectangular region. Table 3.10 explains the parameters. 


Table 3.10 CreateRoundRectRgn Parameters 
CreateRoundRectRgn Parameter Purpose 


nLeftRect The left x-coordinate of the bounding rectangle 

nTopRect The top y-coordinate of the bounding rectangle 

nRightRect The right x-coordinate of the bounding 
rectangle 

nBottomRect The bottom y-coordinate of the bounding 
rectangle 

nWidthEllipse The width of the ellipse used to round the 
corners 

nHeightEllipse The height of the ellipse used to round the 
corners 


D deting a region is accomplished using DeleteObject, just like any other GDI object. 


USING REGIONS 


T he most common use of a region is for clipping. Clipping is а method by which you draw on only a cer- 
tain portion of your drawing area, similar to an artist's use of a graphical template (you know... the little 
plastic thingamajig with circles cut into it). 


To use a region for dipping, you simply bring it into a device context using 
SelectObject. Unlike other types of GDI objects, selectObject does- 
nt return the previously selected region for that device context. Instead, it NOTE 


returns one of the following values: Regions are the only 
= SIMPLEREGION T heregion consists of a single rectangle GDI objects for 
= COMPLEXREGION T he region consists of more than one rectangle which this strange 
= NULLREGION The region is empty behavior occurs. 


Let's do a quick example to show you how to use regions for dipping. 
Load up IsoH e3 3.cpp. 
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T his example has a few extra global variables: 


//pens, old and new 
HPEN hpenNew=NULL; 
HPEN hpenOld=NULL; 
//region 

НКСМ hrgnClip=NULL; 


Also, Prog_Init and Prog_Done have been modified: 


bool Prog_Init() 

{ 
//create a solid red pen 
hpenNew=CreatePen(PS_SOLID,0,RGB(255,0,0)); 


//retrieve the client rectangle for the window 
RECT rcClient; 
GetClientRect(hWndMain,&rcClient); 


//create an elliptical region 
hrgnClip=CreateEllipticRgn(0,0,rcClient.right,rcClient.bottom) ; 


//borrow the ас from the main window 
HDC hdceGetDC(hWndMain); 


//select the new pen into the dc, and keep the old one 
hpenOld=(HPEN)SelectObject(hdc,hpenNew) ; 


//select the clipping region into the dc 
SelectObject(hdc,hrgnClip); 


//make vertical stripes 
int nStripex=rcClient.right/10; 
int nCount; 


// loop through and draw the stripes 
for (nCount=0;nCount<10;nCount++) 
{ 


//move to the top of the client area 
MoveToEx(hdc,nStripex*nCount,0,NULL) ; 


//\ine to the bottom of the client area 


LineTo(hdc,nStripeX*nCount,rcClient.bottom); 
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//make the horizontal stripes 
int nStripeY=rcClient.bottom/10; 


//loop through and draw the stripes 
for (nCount=0;nCount<10;nCount++) 


{ 


//move to the left of the client area 
MoveToEx(hdc,0,nStripeY*nCount , NULL); 


//line to the right of the client area 
LineTo(hdc,rcClient.right,nStripeY*nCount); 


//return the borrowed dc to the system 
ReleaseDC(hWndMain,hdc); 


return(true);//return success 


void Prog Done() 


{ 


//borrow the ас from the main window 
HDC hdc=GetDC ( 


WndMain); 


//restore the old pen 


Sel 


ectObject(hd 


c,hpenOld); 


//return the dc to the system 


Rel 


easeDC( hWnd 


//delete our gd 


Del 
Del 


eteObject(hr 
eteObject (hp 


ain,hdc); 


i objects 
gnClip); 
enNew); 
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W ithout the region stuff, you'd get horizontal and vertical stripes (10 of each) running the length and 
width of your windows client area. W ith this example, you get the same effect, but the lines only get writ- 
ten to the elliptical area you have selected as the clipping region, as shown in Figure 3.3. 


E IsoHex 3-3 x] | Figure 3.3 


Elliptical region 


For the moment, click on another window, obscuring this window, and then switch back to the first win- 
dow. You might see something like Figure 3.4. 


ШЕ IsoHex 3-3 ЕЗ FIG 34 


The dangers of using 
clipping regions 
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As you can see, W indows doesnt erase the part that lies outside of the clipping area. T his is an important 
thing to think about when using regions. It’s always best to keep a region that encompasses the entire client 
area that you select into the D C after you no longer need a DC that covers only a portion. 


To see the differences between the various clipping areas you can have, let's modify IsoH ex3_3.cpp slightly. 
Replace the line with Create£11ipticRgn In it with the following line: 


hrgnClip=CreateRoundRectRgn(0,0,rcClient.right,rcClient.bottom,rcClient.right/2,r 
cClient.bottom/2); 

If you run this again, you'll see the same stripes, only now they are bounded by a rounded rectangle, as 
shown in Figure 3.5. 


isc 33 м 


Rounded rectangle 
clipping region 


Н eres something you may have NOTE 


noticed: when you use these Why are nonrectangular regions slower than rectangular 
rounded regions, the program ones?T he answer is that even a circular or elliptical region 
loads rather slowly; this is the still consists of rectangles. Most of these rectangles are 
main downfall of regions. just a single pixel high. When you then take that region, 
Rectangular regions are much select it in a device context, and use it to clip your output, 


each pixel drawn has to be compared to this gigantic list 
of rectangles to check whether or not the pixel is within 
the clipping area. As you might imagine, this can take 
quite a bit of time if the clipping region is oddly shaped. 
For this reason, when performance counts, use only 

rectangular regions, and use regions only if you absolute- 
ly must. 


faster than curved ones. 
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Change that line again to read as follows: 
hrgnClip=CreateRectRgn(0,0,rcClient.right,rcClient.bottom) ; 


W hen you compile and run this, it should come up a bit faster than the others did, because it’s much easi- 
er to clip to a rectangle than an ellipse or a rounded rectangle (computers dont like doing curves). 


Were going to do one more little modification, using a polygon region. Replace the region creation func- 
tion with the following code 


POINT ptVertice[4]; 
ptVertice[0].x-rcClient.right/2; 
ptVertice[0].y-0; 

ptVertice[1].xercClient.right; 
ptVertice[1].y-rcClient.bottom/2; 
ptVertice[2].x-rcClient.right/2; 
ptVertice[2].y=rcClient.bottom; 

ptVertice[3].x=0; 
ptVertice[3].y=rcClient.bottom/2; 
hrngClip=CreatePolygonRgn(ptVertice,4,ALTERNATE); 


T his sets up a small array of points and creates a polygonal region based on them, using the ALTERNATE 
fill mode. (Refer to Chapter 2, "T heWorld of GDI and W indows Graphics,” for the different polygon fill 
modes.) Figure 3.6 shows what this region looks like. 


Ыш IsoHex 3-3 ЕЗ Figure 36 
A polygon clipping 
region 
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You'll notice that this polygon region takes longer to run than a rectangular region but is not quite as slow 
as one of the curved regions. Clipping to arbitrary lines is still more difficult than a rectangle, but it's easi- 
er than dipping to curves. 


OTHER USES FOR REGIONS 


W hile clipping is the most prevalent use for regions, it is not the only use. You can also use regions to fill 
in arbitrary shapes, as you would a rubber stamp on paper. 


| wont spend too much time on this subject; 111 just list a few functions and leave you to experiment with 
them. You wont be seeing these functions again, but | didnt feel right leaving the topic of regions without 
at least showing them to you. 


TiLLTiÁGN 


BOOL FillRgn( 
HDC hdc, // handle to device context 
HRGN hrgn, // handle to region to be filled 
HBRUSH hbr // handle to brush used to fill the region 


T his returns nonzero on success or 0 on failure. Fills a shape (specified by hrgn) on nac using a 
brush (hbr). 


T^HiNTTÁGN 


BOOL PaintRgn( 

HDC hdc, // handle to device context 

HRGN hrgn // handle to region to be painted 
E 


T his is similar to the Fi11Rgn function, except that the brush used to fill the region is the one that is cur- 
rently selected into the hac. 


FRAMERGN 


BOOL FrameRgn( 
HDC hdc, // handle to device context 
НКСМ hrgn, // handle to region to be framed 
HBRUSH hbr, // handle to brush used to draw border 
int nWidth, // width of region frame 
int nHeight // height of region frame 
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T his returns nonzero on success or 0 on failure. It outlines the region with a brush. nwidth and nHeight 
are the width and height of the frame used to surround the region. 


Take а breath. W еге done with regions. T hat leaves only one GD! object to cover, easily the most impor- 
tant of all. 


CRETING AND USING BITMAPS 


And, at long last, bitmaps! [п your games, bitmaps (in whatever form) will be your stock in trade Y our ter- 
rain, your units, and just about everything else will exist in the form of bitmaps that you will load into 
your program and use on-screen. 


You'll be primarily concerned with two types of bitmaps: those that are blank, and those that you load 
from disk. 


CREATING A BLANK BITMAP 


To create a blank bitmap, use CreateCompatibleBitmap. A compatible bitmap has the same color format 
of a device context (you usually borrow the D C from the main window and make your blank bitmaps 
compatible with it). 


НВІТМАР CreateCompatibleBitmap( 


HDC hdc, // handle to DC 
int nWidth, // width of bitmap, in pixels 
int nHeight // height of bitmap, in pixels 


)n 


T his returns a handle to the created bitmap. Table 3.11 explains the parameters. 


Table 3.11 CreateCompatibleBitmap Parameters 
CreateCompatibleBitmap Parameter Purpose 


һас Тһе device context with which this bitmap 
is to be compatible 
nWidth The width of the bitmap 


nHeight The height of the bitmap 
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CAUTION 


A bitmap created by a call to CreateCompatibleBitmap will contain 
garbage (whatever information was in that memory before the bitmap 
was created). In order to fix this, it must be selected into the DC and 
cleared out using Fi11Rect or the like. 


LOADING A BiTmMmAP FROM Отек 


To load a bitmap from disk, use LoadImage. LoadImage IS used not only for bitmaps, but also for icons 
and cursors. As a result, the return type has to be typecast. 


HANDLE LoadImage( 
HINSTANCE hinst, // handle to instance 


LPCTSTR lpszName, // name or identifier of the image 
UINT uType, // image type 

int cxDesired, // desired width 

int cyDesired, // desired height 

UINT fuLoad // load options 


E 


T his returns a generic handle, which must be typecast into the proper handle type. Table 3.12 explains the 
parameter list. 


Table 3.12 Loadimage Parameters 
Loadimage Parameter X Purpose 


hinst If this bitmap were a resource within the executable, this 
would be the application's handle. Since you are loading 
from disk, this can be NULL. 


lpszName The file name of the bitmap you want to load 
uType The type of image to load (one of IMAGE BITMAP, 

IMAGE CURSOR, Or IMAGE, ICON) 
cxDesired The desired width of the bitmap (0 for the default width) 
cyDesired The desired height of the bitmap (0 for the default height) 
fuLoad Flags.W hen loading a bitmap, this should be LR LOADFROM- 


FILE: 
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USING A BITMAP 


In order to be of any use, a bitmap must be selected into a device context. Since you usually dont want 
bitmaps selected into your window's D C, you will create memory DCs. 


Н еге are three code snippets. W hen you load bitmaps, create blank bitmaps, or get rid of a bitmap, these 
three code snippets are rather close to the actual code you will need. 


GNIPPET 18 CREATING A BLANK BITMAP 


In this first code snippet, you do all the work necessary to create a blank bitmap except for clearing it out 
With Fi11Rect. By the end of this snippet, hdcMem is a memory DC, nbmNew contains a newly created 
bitmap, nbmo1d contains the bitmap originally in hdcMem, and the new bitmap is selected into the new 
DC. 


////////////////////////////////////// 
//Creating a blank bitmap 
////////////////////////////////////// 
//borrow window’s dc 

HDC hdcCompatible=GetDC(hWndMain) ; 
//hdcMem is an HDC global 
hdcMem=CreateCompatibleDC(hdcCompatible); 
//hbmNew is an HBITMAP global 
hbmNew=CreateCompatibleBitmap(hdcCompatible,WIDTH,HEIGHT); 
//return the borrowed dc to the system 
ReleaseDC(hWndMain,hdcCompatible); 

//hbmO0ld is an HBITMAP global 
//select new bitmap into dc 
hbmOld-(HBITMAP)SelectObject(hdcMem,hbmNew) ; 


сміРРЕТ Z: LOADING A BitTmMAP FROM Олек 


You may notice that there is very little difference between the first snippet and the second. T hat's because 
the only difference is where you obtain the bitmap. In other words, you use LoadImage instead of 
CreateCompatibleBitmap. 


/////////////////////////// 
//Loading a bitmap 
/////////////////////////// 
//borrow window’s dc 

HDC hdcCompatible=GetDC(hWndMain) ; 
//һасМеп is an HDC global 
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hdcMem-CreateCompatibleDC(hdcCompatible); 

//return the borrowed dc to the system 

ReleaseDC(hWndMain,hdcCompatible); 

//hbmNew is an HBITMAP global 
hbmNew-(HBITMAP)LoadImage(NULL,"FileName.bmp", IMAGE BITMAP,0,0,LR LOADFROMFILE); 
//hbmOld is an HBITMAP global 

//select new bitmap into dc 

hbmOld-(HBITMAP)SelectObject(hdcMem,hbmNew) ; 


SNIPPET Sit CLEANING UP 


T his final snippet returns the original bitmap into the memory device context and deletes the bitmap and 
the device context. 


////////////////////////// 
//Getting rid of a bitmap 
ИИ! 
//restore old bitmap to dc 
SelectObject(hdcMem,hbm01d); 
//delete bitmap 
DeleteObject(hbmNew) ; 
//delete dc 
DeleteDC(hdcMem) ; 


T here: short, sweet, and for general use. 


Consider the lengths of these code snippets. T hey aren't long, but if you had 100 bitmaps, they would add 
up quickly. Dont worry— later we'll develop a class to help wrap this up into a neat package (O h, dont 
groan like that. It'll be easy.) 


TUTELT 


N ow comes the fun part— moving information from one device context to another. T his is called blitting, 
and the primary function in GDI to do this task is called Bi tB1t. (BitB1t stands for “bit block transfer") 


BOOL BitBlt( 
HDC hdcDest, // handle to destination DC 
int nXDest, // x-coord of destination upper-left corner 
int nYDest, // y-coord of destination upper-left corner 
int nWidth, // width of destination rectangle 
int nHeight, // height of destination rectangle 
HDC hdcSrc, // handle to source DC 
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int nXSrc, // x-coordinate of source upper-left corner 
int nYSrc, // y-coordinate of source upper-left corner 
DWORD dwRop // raster operation code 


i 


T his returns nonzero on success or 0 on failure Table 3.13 explains the parameter list. 


Table 3.13 BitBit Parameters 
BitBlt Parameter Purpose 


dcDest The destination device context 

XDest The destination x-coordinate 

YDest The destination y-coordinate 

Width The destination width 

Height The destination height 

ас5ғс Тһе source device context 

XSrc The source x-coordinate 

Sine The source y-coordinate 
dwRop The desired raster operation 


BitB1t Copies the contents of the source device context (hdcSrc), starting at nxSrc,nYSrc and copying a 
width of nwidth and a height of nueignt to the destination device context (hdcDest) at nXDest ,nYDest. 
It combines the source with the destination, depending on the value of dwRop. 


A WORD AROUT RASTER OPERATIONS 


M ost of the parameters of BitBit аге self-explanatory; however, dwRop is not among them. A raster oper- 
ation is just a manner in which the source and destination pixels in a blit are combined. 
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Table 3.14 lists some of the more commonly used raster ops. 


Table 3.14 Raster Ops 


Raster Operation Constant Meaning 


SRCCOPY The source is copied to the destination with no regard 
for the contents of the destination. 

SRCAND The source and destination are combined using the 
AND operation. Useful for bitmasking. 

SRCPAINT The source and destination are combined using the ов 
operation. Useful for adding images while being nonde- 
structive. 

SRCINVERT The source and destination are combined using the 


XOR Operation. Blitting the same image to the same 
location twice using SRCINVERT restores the original 
contents of the destination. Useful for custom cursors. 


Example time. Load ир 150Н ex3_4.cpp, and be sure to havelsoH ei 4.bmp in the same folder as 
the project. 


In this example, clicking the mouse button blits a bitmap onto the window. In Prog Init and Prog Done, 
| simply modified the code snippets we covered a little earlier (so | wont repeat them here). T he work is 
done by the wM_LBUTTONDOWN handler in TheWindowProc. 
case WM LBUTTONDOWN: 

{ 


//borrow ас from main window 

HDC hdc=GetDC(hWndMain) ; 

//blit from the memory dc to the window’s dc 

BitBlt(hdc, LOWORD(1Param)-BITMAPWIDTH/2,HIWORD(1 Param) - 
BITMAPHEIGHT/2,BITMAPWIDTH,BITMAPHEIGHT,hdcMem,0,0, SRCCOPY) ; 

//return the borrowed dc to the system 

ReleaseDC(hWndMain,hdc); 

//handled, so return 0 

return(0); 

}break; 
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BITMAPWIDTH and BITMAPHEIGHT are just constants that | added earlier in the application. 
Figure 3.7 shows what this application looks like. 


Би IsoHex 3-4 x| ROO 


Blitting bits 


You may notice that one image may overwrite part of another if they аге too close together. T his is 
because you are using $вссорч, which has no regard for the destination image. 


M odify IsoH ex3 4.срр to use SRcPAINT instead, as shown in Figure 3.8. 


ii IsoHex 3-4 Fere 38 
Demonstrating the 


SRCPAINT raster 
operation 
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Well, now you dont have the problem of the black corners obscuring the image below, but the images start 
to sort of merge, and it's hard to tell where each one is. Т he reason for this is that the image uses only 
three colors— black (RG B(0,0,0)), dark green (RGB(0,128,0)), and bright green (RGB(0,255,0)). 


Table 3.15 specifies how each of these combine when using SRCPAINT. 


Table 3.15 Color Combination Using SRCPAINT 


Source Pixel 


Black Dark Green Bright Green 

SRCPAINT | RGB(0,0,0) | RGB(0,128,0) | RGB(0,255,0) 
Black Black Dark Green Bright Green 
RGB(0,0,0) | RGB(0,0,0) | RGB(0,128,0) | RGB(0,255,0) 
Dark Green Dark Green Dark Green Bright Green 
RGB(0,128,0) |RGB(0,128,0) | RGB(0,128,0) | RGB(0,255,0) 
Bright Green | Bright Green | Bright Green | Bright Green 
RGB(0,255,0) |RGB(0,255,0)| RGB(0,255,0) | RGB(0,255,0) 


BiTwWist OPERATOR REVIEW 


If you're confused, I'm about to help. Let's review for a moment some of the bitwise operators— namely, 
AND, OR, and хок. Рог a given combination of bits, you combine them in different ways. лмо yields а TRUE 
(1) only if both source bits are true. ов yields a TRUE as long as at least one of the source bits is true. хов 
yields TRUE only if one but not both of the source bits are true. Table 3.16 is a combined truth table for 
these operators. 


Destination Pixel 


Table 3.16 Truth Tables for AND, OR, and XOR 
First Bit Second Bit First AND Second First OR Second First XOR Second 
0 0 0 


[— O = (ео 
Se eS (Се) 


0 0 1 
1 0 1 
1 1 1 
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How Bitwist OPERATORS ComkEINE COLORS 


N ow, let's examine two colors, bright red (RGB(255,0,0)) and bright blue (RG B(0,0,255)). First, you 
must convert these colors into their binary equivalents. 


NOTE 


If you look back at the RGB macro in Chapter 2, you see that the 
green component gets shifted left by 8 bits and the blue compo- 


nent gets shifted by 16 bits, so the binary formats look some- 
thing like this: 
Bright Red 00000000 00000000 11111111 
Bright Blue 11111111 00000000 00000000 


N ext, combine the individual bits using the appropriate bitwise operator. 


AND 
00000000 00000000 11111111 (red) 
11111111 00000000 00000000 (blue) 


00000000 00000000 00000000 (black) 


Т he result is black (RGB(0,0,0)). W hen you AND red and blue, you get black, because red and blue have no 
bits in common. 


OR 
00000000 00000000 11111111 (red) 
11111111 00000000 00000000 (blue) 


11111111 00000000 11111111 (magenta) 


T he result is magenta (RGB(255,0,255)). Since either or both bits can be set to yield a 1, you thus һауе а 
1 for any column in which there is at least a single 1. 
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XOR 
00000000 00000000 11111111 (red) 
11111111 00000000 00000000 (blue) 


11111111 00000000 11111111 (magenta) 


Т he result is magenta (RG B(255,0,255)), which is the same as the result from on. Since the two colors 
have no bits in common, xor combines to make the same result as an ов. 


XOR., TAKE TWO 
Let's take the resulting value and хок it with blue again. 


11111111 00000000 11111111 (magenta) 
11111111 00000000 00000000 (blue) 


00000000 00000000 11111111 (red) 


You are left with red again, because both sets of bits have all blue bits set. T his shows you that xoring the 
same thing twice leaves you with what you started out with. 


Are you wondering what I'm up to, or have you figured it out already? 


RASTER OPERATION EXAMPLE 
Let's do another example. Load up 150Н ex3_5.cpp. 


T his example looks a lot like |5оН ex3 4.cpp. T he main differences аге the lack of a ww LBUTTONDOWN 
message handler, the addition of a global variable and a function, and a modification of Prog Init. 


//cursor location 
POINT ptCursor; 


case WM MOUSEMOVE: 
{ 
//extract x and у from ТРагат 
int x=LOWORD(1Param); 
int y=HIWORD(1Param); 
//borrow window’s dc 
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HDC hdc=GetDC(hWndMain) ; 
//write the cursor 
ShowTheCursor(hdc); 
//update the cursor position 
ptCursor.x=x; 
ptCursor.y=y; 
//write the cursor 
ShowTheCursor(hdc); 

//return dc to system 
ReleaseDC(hWndMain,hdc); 
//handled, so return 0 
return(0); 

}break; 


bool Prog_Init() 
{ 

//borrow dc from main window 

HDC hdc=GetDC(hWndMain) ; 

//create a memory dc 

hdcMem=CreateCompatibleDC(hdc); 

//Лоаа in the bitmap 
hbmNew-(HBITMAP)LoadImage(NULL,"IsoHex3 5.bmp",IMAGE BITMAP,0,0,LR LOAD- 
FROMFILE); 
//select bitmap into memory dc 
hbmOld-(HBITMAP)SelectObject(hdcMem,hbmNew) ; 
//set original cursor position 
ptCursor.x=0; 
ptCursor.y-0; 

//return dc to system 
ReleaseDC(hWndMain,hdc); 
return(true);//return success 


//show the cursor 
void ShowTheCursor(HDC hdc) 
{ 
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BitBlt(hdc,ptCursor.x-BITMAPWIDTH/2,ptCursor.y- 
BITMAPHEIGHT/2,BITMAPWIDTH,BITMAPHEIGHT,hdcMem,0,0, SRCINVERT) ; 
} 


T he ptCursor variable is а POINT, and it keeps track of your "cursor" position. You load IsoH ex3 5.bmp 
(it's a white diamond shape) and select it into hdcMem. In Prog_Init, you give this position an initial value 
of (0,0). It gets shown in the initial call to uM PAINT. 


During the wM_MOUSEMOVE, you call ShowrheCursor again. Since ShowTheCursor USES SRCINVERT to show 
the cursor (using the xor operator), it erases the cursor currently showing. T hen, you update the cursor 
position and show the cursor again. Y ou have just a black background currently, so this doesnt look like a 
big deal. Later, when we get to double buffering, the uses of ShowTheCursor will become much more 
apparent. Figure 3.9 shows the output. 


ШЕ IsoHex 3-5 ЕЗ Figure 33 


Cursor demo 


FAN APPLICATION OF RASTER OPERATIONSE 
BITMASKING 

N ow that you've seen at least one application of raster operations, let's look at another— bitmasking. 
Bitmasking is a method of writing oddly-shaped graphics when you can only blit rectangles. It is one of sev- 
eral methods by which you can achieve transparency. For bitmasking to work you must rely on a few rules 
of bitwise operators. 
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FIRST RULE OF BiTwist OPERATORS 


Any bit, when you AND it with a 1, yields the bit's value. 


0 AND 1-0 
1 AND 1-1 


T herefore, any color anned with white (11111111 11111111 11111111) gives you the original color. 


SECOND RULE OF BITWIst OPERATORS 
Any bit, when you AND it with 0, yields 0. 

0 AND 0=0 

1 AND 0=0 


T herefore, any color anned with black (00000000 00000000 00000000) gives you black. 


THIRD RULE OF KITWISE OPERATORS 
Any bit oned with 0 yields the bit's value. 

0 OR 0-0 

1 OR 0-1 


So, using the preceding three rules, you can write any oddly-shaped graphic using BitB1t and the raster 
operations SRCAND and SRCPAINT. 


Load up 150Н ex3 6.cpp, and be sure to have SoH ex3_ 6- 1.bmp and IsoH ехЗ 6-2 ртр in the project 
folder. Т his example is pretty much just an enhanced 150Н ехз 4.cpp. An extra bitmap is loaded, and dur- 
ing the wM_LBUTTONDOWN, there are two Bit81t Calls instead of just one. | wont put the code here; you can 
take a look yourself. Figure 3.10 shows the output. 


ЕЕ IsoHex 3-6 Figure 3.10 
Bitmasks in action 
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Bitmasking is really important if you're going to use 6 01 to make isometric or hexagonal games (since iso- 
hex games tend not to use rectangular areas). О nce you get into D irectD raw, you'll use transparency 
instead of bitmasking, but it's good to know about bitmasking, since you may still make your level editors 
and tools using GDI. 


A BiTmAP MANAGEMENT CLASS 


As you've сееп, the creation or loading of each bitmap, the selection of then into a device context, and the 
later destruction of then requires several lines of code, and with the more bitmaps and device contexts 
you add, the more code you get. Logically, you would wrap this activity, either in function form or class 
form. l'm something of an object-oriented nut, so I’m going to make a class. If you're aC person, I'll try 
to go easy on you. 


First, our dass (which | call соотсапуаѕ) has two purposes. О ne is to load a bitmap, and the other is to 
make a blank bitmap of an arbitrary size You will make a member function for each of these. Also, our 
dass must take care of deleting all the associated bitmaps and D Cs, so there will be a member function for 
that as well. 


T he data logically contained in ссотСапуаз consists of two handles to bitmaps and а handle to a DC. 
One last thing: | dont want to have to pull out a member each time in order to do a BitB1t using 
CGDICanvas, 50 l'm going to add a conversion operator. 


Н eres the declaration of cGDICanvas (which you can find in GD ICanvas.h): 


class CGDICanvas 

{ 

private: 
//memory dc 
HDC hdcMem; 
//new bitmap 
HBITMAP hbmNew; 
//old bitmap 
НВІТМАР hbmOld; 
//width and height 
int nWidth; 
int nHeight; 


public: 


//constructor 

CGDICanvas(); 

//loads bitmap from a file 

void Load(HDC hdcCompatible,LPCTSTR lpszFilename); 
//creates a blank bitmap 

void CreateBlank(HDC hdcCompatible, int width, int height); 
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//des 
void 


troys 
Destr 


bitmap and dc 
оуО: 


//converts to HDC 


opera 
//ret 


tor H 


DC(); 


rn width 


int GetWidth(); 


//ret 


rn h 


eight 


int GetHeight(); 


//des 


truct 


or 


~CGDICanvas(); 


Private means that you cant touch those members from outside of the class, and public means you can. It's a 
security thing. Allowing the user to play with hdcMem ОГ hbmNew could be disastrous, so | made them pri- 


vate. 


Something else that might be throwing you is the functions in the public section— especially the operator. 
T he power of С++ classes is such that you can take what would normally be a struct (which is what the 
private part of the class looks like) and add functions that operate on that data. 


Н ere are the equivalent С declarations to do the same thing: 


struct GDICanvas 


{ 


I3 

//load 
void G 
lpszFi 
//crea 
void G 
int he 
//dest 
void G 


//me 
HDC 
//new 
НВІТ 
//old 
НВІТ 
//wid 
int n 


int n 


s bit 


ory d 


dcMem; 


bitn 
AP hb 
bitn 
AP hb 
th an 


Width; 


Heigh 


ap 

mNew; 

ap 

mold; 

d height 


ap from a file 


DICanvas Load(struct GDICanvas* pgdic,HDC hdcCompatible,LPCTSTR 
lename); 
tes a blank bitmap 

DICanvas CreateBlank(struct GDICanvas* pgdic,HDC hdcCompatible, int width, 
ight); 
roys bitmap and dc 

DICanvas_Destroy(struct GDICanvas* pgdic,); 
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And there would be nothing wrong with having these declarations. Н owever, since the functions and the 
struct are tightly coupled (the functions are of no use except with the struct), it makes sense to make it a 
dass. 


You may have noticed that some of the functions were missing in the declarations for C. Getting the 
width, height, or hac would just be done through the struct, so the extra functions were unnecessary. Also, 
the cGDICanvas and ~CGDICanvas Were missing (these are the constructor and destructor). In C++, the 
constructor is used to initialize the values of a class, and a destructor makes sure that the class cleans up 
after itself. You never call either of these functions. 


You can take a look at the implementation of ссртсапуаѕ on your own (it's in GDICanvas.cpp). T heres 
not much to it, really. It just has the various code snippets for loading, making, and destroying bitmaps 
and DCs. 


LOADING IMAGES WITH CGDICANVAS 
With caDI Canvas, loading images is much easier. 


//declare а CGDICanvas variable 
CGDICanvas даісІтаде; 

//borrow the window's dc 

HDC hdc=GetDC(hWndMain) ; 

//Лоаа the image 
gdicImage.Load(hdc,"filTename.bmp"); 
//release the window's dc 
ReleaseDC(hWndMain,hdc); 


CREATING A BLANK BiTmMmMAP witH CGDICANVAS 
To create a blank bitmap instead, you can replace gdicImage. Load with this: 


//create blank image 
gdicImage.CreateBlank(hdc,100,100); 


Do this to destroy it later: 
gdicImage.Destroy(); 


You can see that this is a much more simplified process. caDICanvas has а few other features of which you 
should be aware. 
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CGDICANVAS INFORMATION RETRIEVAL FUNCTIONS 
To retrieve the width or height of the image, you can use GetWidth OF GetHeight. 


//get width and height 
int w=gdicImage.GetWidth(); 
int h=gdicImage.GetHeight(); 


CONVERSION TO НОС 
Also, because of the operator HDc(), you can use a CGDICanvas anywhere that an нос is needed. 


//blit from the image 
BitBlt(hdcDst,0,0,gdicImage.GetWidth(),gdicImage.GetHeight(),gdicImage,0,0,SRC- 
COPY); 


You have now drastically simplified your life (at least in the loading and creating bitmaps area) with 
CGDICanvas. 


+ CGDICANVAS EXAMPLE 


Load up 150Н ex3_7.cpp. It requires the use of GDICanvash and GD I Canvas.cpp, so be sure to have them 
in there. Also, be sure to have the |soH e3 7 bitmaps in the project directory. 


Compile and run [50Н e 7.срр. It does the exact same thing as 150Н ехз 6.cpp, except that it uses 
CGDICanvas, Which makes much of the initialization and cleanup code shorter. As you can see, Prog Init 
is quite a bit shorter. 


bool Prog Init() 

{ 
//borrow dc from main window 
HDC hdceGetDC(hWndMain); 
//load the images 
gdicTile.Load(hdc,"IsoHex3_7-1.bmp"); 
gdicMask.Load(hdc, "IsoHex3_7-2. bmp"); 
//return dc to system 
ReleaseDC(hWndMain,hdc); 
return(true);//return success 
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See how much easier it is? 


You'll use GDICanvas quite a bit (which is why it doesnt have a normal IsoH exX Y name). Even when 
you get into D irectD raw, you will still use Got Canvas to load your graphics. 


DOUBLE BUFFERING WITH СОТ 


One thing that may be vexing you is that when you switch from one of the IsoH ex examples and then 
switch back, most if not all of the content is erased 

by the windows that were in front. T his is annoy- 
ing in little sample cases like the ones we have NOTE 


been doing here, but it would be disastrous in any 1 4 

sort of real application (like a game). T his con- 2/5 Дақ але adv Reidel aig va 

alae E ~ hows aan tion. With the examples we've і dope 
еер а copy of your client area, except on the this тт a difficult feat. Just nlaké the/blank 


screen, so if something draws over it you're out bitmap the size of the client area after you 

of luck. have adjusted it. H owever, if you were making 
N ot to worry, though: you can protect yourself an application where the user can resize the 
against losing content by double buffering. A border, you'd have to make the blank bitmap 


D ouble buffe is nothing more than an image larger—say, the size of the entire screen 
stored elsewhere (that is, not on the screen) that Е дайнын АС м 
is copied to the screen as it is needed. То double Енка А ng 

buffer, you need a blank bitmap selected into a ; 

DC, two Styrofoam cups, and a string. (Just kid- 
ding about the Styrofoam cups and string.) 


And what you do with this blank bitmap is write to it instead of to the main window's DC. Doing so cre 
ates a problem, however: updating the window' client area. If you draw to your double buffer, you cannot 
see the double buffer unless you copy it onto your window; there are a few ways in which you can do so. 
One, you could blit the contents of the double buffer to the window every frame (in Prog. Loop). T hat's 
one solution, but not the one you want. Two, you could update only the regions that change. As a game 
programmer, you never want to draw anything you dont have to, and you especially never want to redraw 
anything you dont have to. So solution one is out, and two is in. 


H ow to implement this fine idea? U se an update rectangle. H eres how it will work: if the update rectangle 
is an empty rectangle, you will do no drawing; if the update rectangle is not empty, you will copy the con- 
tents of the double buffer to the screen, but only from that rectangle. N ow that you know how you'll be 
drawing with it, you also need to know how you'll determine the update rectangle. 
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W hen the update rectangle is enpty, any rectangle added to it becomes the new update rectangle W hen 
the update rectangle is not empty, any rectangle added to it is combined with the new rectangle using 
UnionRect.W hen им PAINT is called, you add a rectangle the size of the client area to the update 
rectangle. 


DOUBLE BUFFER EXAMPLE 
Load up 150Н ex3 8.cpp. You'll need the IsoH ex3 8 bitmaps, GD ICanvas.h, and G D I Canvas.cpp. 


A gain, this example looks exactly like IsoH ex3 6 and IsoH e 7. H owever, if you switch to another 
application and obscure some or all of the example, when you return, the contents of the client area 
remain because of the double buffer (gdicBackbuffer in the code). 


CREATING THE DOUBLE BUFFER 
Creation of the double buffer consists of simply a few function calls: 


//get the client rectangle 
RECT rcClient; 
GetClientRect(hWndMain,&rcClient); 

//create a blank bitmap with the client area’s dimensions 
gdicBackbuffer.CreateBlank(hdc,rcClient.right,rcClient.bottom) ; 

//clear out the blank bitmap 
FillRect(gdicBackbuffer,&rcClient, (НВЕОЅН ) GetStockObject(BLACK BRUSH)); 
//clear the update region 

ClearUpdate(); 


First, you get the client area so that you can create a double buffer of adequate size. N ext, you clear out 
the double buffer with a black brush (a stock object). Finally, you clear out the update area (making sure 
that you initialize it properly). 


T he update rectangle itself is contained in a global variable called rcUpdate, declared near the top of the 
source file. 
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UPDATE RECTANGLE MANAGEMENT 


M anagement of the update rectangle is done by use of three functions: clearUpdate, AddUpdate, and 
RenderUpdate 


ClearUpdate is rather simple. It just sets the update rectangle to empty. 


//clears the update rectangle 

void ClearUpdate() 

{ 
//set the update rect to empty 
SetRectEmpty(&rcUpdate); 


AddUpdate does one of three things, depending on the current update rectangle and the rectangle 
being added. 


= |f you are attempting to add an empty rectangle, it returns immediately, because no real work needs to 
be done. 

a |f the current update rectangle is empty, it copies the added rectangle to the update rectangle. 

= |f the current update rectangle is not empty, AddUpdate uses UnionRect to combine the two rectangles 
and places that union into rcUpdate. 


//adds the update rectangle 
void AddUpdate(RECT* prcAdd) 
{ 
//if the new rectangle is empty, return without doing anything 
if(IsRectEmpty(prcAdd)) return; 
if(IsRectEmpty(&rcUpdate) ) 
{ 
//if the rectangle is empty 
//copy the new rectangle to the update rectangle 
CopyRect(&rcUpdate,prcAdd) ; 


else 
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//if the rectangle is not empty 

//create a temporary rectangle 

ВЕСТ гсТепр; 

//combine the new rectangle with the old rectangle in the temporary rect 
UnionRect(&rcTemp, &rcUpdate, prcAdd) ; 

//copy the temporary rectangle to the update rect 
CopyRect(&rcUpdate,&rcTemp) ; 


RenderUpdate does one of two things. 


= |f the update rectangle is empty, there is no need to render anything, so it returns immediately. 
= |f the update rectangle is not empty, it grabs the D C from the window supplied in hwndDst, copies over the 
part of hdcSrc corresponding to rcUpdate, and finally clears out the update rectangle. 


//renders the update 
void RenderUpdate(HWND hwndDst, HDC hdcSrc) 
{ 
//if the update rectangle is empty, return without doing anything 
if(IsRectEmpty(&rcUpdate)) return; 
//Боггом the dc from the destination window 
HDC hdcDst-GetDC(hwndDst); 
//blit the update area 
BitBlt(hdcDst,rcUpdate.left,rcUpdate.top,rcUpdate.right- 
rcUpdate.left,rcUpdate.bottom-rcUpdate.top,hdcSrc,rcUpdate.left,rcUpdate.top,SRC- 
COPY); 
//return the destination dc to the system 
ReleaseDC(hwndDst,hdcDst); 
//clear the update area 
ClearUpdate(); 


D ouble buffering is а good tool for any application that has to live in a window. R edrawing all content 
each frame is a hassle, and it can kill performance. U sing a double buffer and an update rectangle can 
streamline the process somewhat. 
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SUMMARY 


You thought | was going to go on forever about bitmaps, didnt you? W ell, it was necessary. It's an impor- 
tant topic, and I'm still not entirely sure! gave it all the attention it deserves. In any case, | certainly hope 
I've given you enough GDI stuff to work with. 
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CHAPTER 4 
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elcome to the wonderful world of DirectX !W ith it, you can grab control of your machine's 

capabilities and do alot more а lot faster than with W indows. In the dark days before D irectX , 
taking full advantage of the enhanced capabilities of hardware was the domain of D O S applications. T he 
first fledgling version of DirectX did little better. N ow things are pretty darn good, and DirectX has 
become the norm for game programming for theW indows platform. 


DIRECTX COMPONENTS 


DirectX 7 (which, because of backward compatability, is included with DirectX 8) has a number of com- 
ponents, of which you'll use only a scant few. T he main components and their uses are as follows: 


= DirectD raw (D D ).Т he visible component of DirectX , D irectD raw encapsulates your video driver(s). W ith 
D irectD raw, you control the resolution of the screen, the system cooperation with the windowed environ- 
ment (either full-screen or windowed). You also control the use of display memory. D irectD raw allows you to 
program the machine independently for a variety of video cards. 

= Direct3D (D3D).Direct3D is a cousin of DirectD raw. (In DirectX 8, DirectD raw and Direct3D will be 
combined.) It encapsulates a 3D hardware driver if one is present or emulates one if needed. Like 
D irectD raw, D3D achieves device independence. Н ardware support in the driver allows the use of more of 
D 3D $ advanced features. 

= DirectSound (D S). T he audible component of DirectX , DirectSound encapsulates a computer's sound driv- 
ers. It is used to play digital sounds in a machine-independent manner. 

= DirectM usic (DM ).T his is DirectSound's cousin. It allows an easy (well, not easy) way to play music on a 
variety of machines while still having it sound the same. 

= DirectInput (D I). D irectinput encapsulates the drivers for various input devices, like keyboards, mice, joy- 
sticks, gamepads, flight-yokes, and a variety of specialized controllers. 

= DirectPlay (D P). D P encapsulates network drivers, allowing an independent way to ge information from 
one computer to another, making multiplayer games easier to create. 

= DirectSetup. A minor component of DirectX , DirectSetup allows you to install the latest release of D irectX 
on a user's machine with a few simple function calls. In addition, it allows customization of the interface you 
present to the user during the setup process. 


DIRECTX CONFIGURATION 


Before you get flying, you need to get DirectX set up on your machine. T he first step in doing so is 
installing the Software D evdoper's Kit (Installing the SDK is covered in Appendix А). О псе you have the 
SDK installed, select Tools, O ptions, as shown in Figure 4.1. 
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* Microsoft Visual С++ 4 Figure 4.1 
|| Ble Ко Yew јава Project р.да | Took Window Hep 
ou A te]: eremi Selecting Tools, 


Options 


You will see the O ptions dialog box, as shown in Figure 4.2. Click on the Directories tab, and make sure 
that the top two combo boxes read W IN 32 and Include files. 


(5. Microsoft Visual С++ 4 Figure 4.2 
|е Ка Vien мел Project Quid Tools Window Hep l | | 
тағ менее ||| ЖҮ ШО | The Options dialog box 


Соот Fies\Microsott Visual Studo VCSS\MFCUNCLUDE 


Слот Files\Microsolt Visual Studio \VCS8\A TL UNCLUDE 
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Click on the first empty line in the list box, and enter the path to the SDK s Include folder, or use the 
ellipsis button (...) to browse for it, as shown in Figure 4.3. 


*,. Microsoft Visual С++ Figure 4.3 
Adding a folder 


C AProgram Нез Мк nal Stucke VICSENINCLUDE 
Соат FlesMMucsosoft Visas Studie NVICIESMÉ CUNG. ОЕ 
у муу 


N ow, dick on опе of the other items to unselect that line, and use the up arrow button to move your new 
entry to the top of the list box. (See Figure 4.4.) 


*, Microsoft Visual С++ 2x Figure 4.4 
Пре Edt Уен juam Project Quid Tools Window Heb un 
о.о. BDAY саан а Bringing the new 
folder to the top of 
the list 


САРмуат FlesNMaciosoft Visus Studio VCSIINCLUDE 


Сауат Fles\Mictosolt Visus Studio\VCS8\MFCUNCLUDE 
C \Progam Files\Miciosolt Visus Stude\VCS8\ATLUNCLUDE 
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Finally, do the same thing for the library files. T he result is shown in Figure 4.5. 


*, Miciosolt Visual С++ 


Ге Ба View jet Project Quid Tools Window Help 


Figure 4.5 


Library directories 


Editor | Tabs | 04; | Compariilty | Ould (бекшш | 
Patioen 
[уез E 
Ба 


Shore deectones foc 


C'VPhogiam Fiesi Microsoft Visus Studie VESES 


Сут Flles\Micinsoft Visus Studie NV CSENMECN. IB 


T hankfully, you have to do this only once and all the applications you write will have DirectX available 
to them. 


W dl, almost. T here is one last thing you have to do for each application. W hen you are working on your 


application (and it's best to set this up somewhat early in the development so you wont forget and get a 
bazillion errors), select Project, Settings, as shown in Figure 4.6. 
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у. іоНек3 8 - Microsoft Visual С++ - ПвоНекЗ_8.срр] 3E Figure 4.6 
[3 pe га уен niet Proet fud Tools Window Help ; ; 
dig Г. ehm Г шшш 2. Project, Settings 


6599 To Project , 
[ЕУ i 
Ogperdences. 


rcUpdate.&rclenp) 


Workspace 1ecHex3 8 
E tsottex3_8 мез 


HUND hendDet, HDC 


it(IsRectEmpty(&rcUpdate)) return 


HDC hdcDst*GetDC(hvndDst ) 
BitBlt(hdcDst .rcUpdate. left rcUpdate top. zcUpdate right-rcUpdate. lef 
RelesseDC(hvndDst.bdcDst) 


ClearUpdate() 


[XN вым (Debug Fede Fles 1, Find in Fles 2, Renis 7 141 


Alternatively, you can press Alt+F7 to get to the same place. 
After you have done either of these, you will be met with the dialog box shown in Figure 4.7. 


*. IaoHex3 i - Microsoft Visual С++ - |зоНек2 0 cpp) Figure 4.7 

О Ве Ede уен |nie Project [uid Tools Window Heb | 
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[шн E E Settings dialog box 


Project Settings 
Wod space Trot 
ga IzoHex3 + Gellings For [Wna Debug z] 


C3 золе ГГ 
3) 60 


cUpdate. let 


КІП вым (Debug) ӘРІ 2991,7 У  141| 
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Click on the Link tab, shown in Figure 4.8. In the O bject/ library modules text box, add any extra libs to 
which you want to link. In the case of DirectD raw, you'll want to put in ddraw.lib and dxguid.lib. 


*, ІзоНек3 0 - Microsoft Visual C++ - |ПзоНек2 8 cpp} JE Figure 4.8 
(Әне Kd уен Inset Dopet Quid Tools Window Help 

асы ье о. 2. mme eet ІСТЕ ИС) The Link tab 
EEE 000-0000 —-—ÁÀ = ZH 
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ёна [ы [wind2 Debug =] 
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Г Enable profiing 

Propet Options 

апа кетеі52 № user? № 92 № 


ага росй lib cormdig32 lib advagc2 № sheti? № 
iole32 № деэ 72% uud lb odbc 32 № odbccp32 № > 


W hen you get to DirectSound a little later, you'll add 
dsound.lib and winmm.lib to this list as well. 


р А When you're developing, you пог- 
2. you need to do to set up your compiler to use málly dre Th the Deby chnfigura- 
МСА tion. W hen it comes time to dis- 

tribute your code, you'll switch to 
TRADITION AND COM the Release configuration. W hen 


you do so, you'll have to select 
In every book ever written about D irectX , the tradition is to Projects, Settings because the 
spend some time talking about how D irectX works and how libraries you link depend on what 
COM works. W ho am | to break with tradition? configuration you are in. 


COM stands for Component О bject M odd. H mm. You 

dont seem particularly impressed. O К.Т he why and wherefore 
of COM is pretty boring stuff anyway. Instead, let me tell you what COM can do for you, as far as 
DirectX programming is concerned. N umber one no matter what version of DirectX you 

use to write your game, it will run on any machine that has that version or later of the D irectX runtime 
installed on it. N umber two: when you use DirectX objects, most of the housekeeping is done for you. 
You create your objects with the various create functions and member functions, and you release them 
when you no longer need them. Each Create is paired with a Release, and that's all you have to do. 
COM and DirectX take care of the rest. 
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VERSION CONTROL 


First, let's address DirectX benefit number one, version control. You'll be using DirectX version 7.T his 
version has a number of interfaces (an interface is just a set of functions used to access an object). T hese 
interfaces аге IDirectDraw7, IDirectDrawSurface7, and IDirectDrawCli pper.T here are a few others 
that you wont be using. 


In order for users to run your program, they must have D irectX 7 or later installed on their systems. 

H owever, what happens when later versions come out, and what happens if they drastically change the way 
things аге done? N ot a problem. 1DirectDraw7 and the rest will still be there, and new interfaces will have 
been made available to access the latest features. 


Pretty cool. T his means you can get a copy of some of the stuff | did using DirectX 5, and it'll still work. 
Backward compatibility is cood. 


REFERENCE COUNTING 


N ow, DirectX benefit number two. As І said before, you'll be using a number of interfaces. | also 
explained that an interface is just a set of functions that allow you to talk to an object. [п most cases in 

D irectX , the existence of one object depends on the existence of another object. N amely, an 
IDirectDrawSurface7 Object depends on an [DirectDraw7 object to work properly. T his could be disas- 
trous if you deleted the 1DirectDraw7 object (by calling its Re1ease function) before you were done 
using the IDirectDrawSurface7 object. 


T hat's where CO M 5 reference counting comes in. W hen you create your 1Directbraw7 object, its refer- 
ence count becomes 1. W hen you use that object to create ап IDirectDrawSurface7 object, it is increased 
to 2.W hen the 1DirectDraw7 object is released, it drops to 1 again, but it is not deleted, because 
IDirectDrawSurface7 still needs it. О nly when 1DirectDrawSurface75 Release Is called is the 
IDirectDraw7 Object deleted. 


If you design a dass or module that depends on one or more of DirectX 5 objects, you can also make use 
of reference counting. T hat is, if you design a class or module that needs an object, you can call AdaRef to 
increment the reference count, and Re1ease When you no longer need the object. 


If you didnt get all of that in a single pass, dont worry. Suffice it to say that COM and DirectX protect 
you from yourself somewhat, but, of course, this doesnt give you a license to be sloppy. 
SUMMARY 


T his short chapter just showed you how to get DirectX up and running on your machine. We'll be getting 
into D irectD raw next, so be prepared. 
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CHAPTER 5 


USING 
DIRECTÖ RAL 


а CREATING THE 1DIRECTORAWTZ7 
ORJECT 


а SETTING THE COOPERATEIVE LEVEL 


"п ENUMERATING DISPLAY MODES 


USING DiRecTORAW FEES 


irectD raw (DD), along with its cousin, Direct3D (030), is the visible component of D irectX , 
Г) and traditionally, it is always the first component a person new to DirectX learns. DD has one 
primary task, and that is granting you control over your video hardware— something that you wouldn't 
otherwise have under W indows. Or, at least, you couldnt control it very well or with any sort of good pe- 
formance. 


T his chapter will get you up to speed on the component of DD that exerts your control over display 
resources, the IDirectDraw7 interface Chapter 6, “Surfaces,” covers D D's stock in trade, 
IDirectDrawSurface7 and IDirectDrawClipper. 


CREATING THE 1IDIRECTORAWZT OBJECT 


All of the DirectX interfaces are used through the use of pointers, and each object has a special typed 
pointer that you use to talk to its interface. [п the case of 1DirectDraw7, this pointer type is LPDTRECT- 
DRAW7. Їп a game or application, you need only one of these (unless you have а multiple-monitor system, 
in which case you could use two or more, but multimon systems are beyond the scope of what I'm show- 
ing you here). 


So, when using D D, always declare a global variable that points to an 10i гес+ргамт interface: 


//IDirectDraw/7 pointer 
LPDIRECTDRAW7 1pdd=NULL; 


And somewhere early in your initialization (Prog_Init), create your object using Di rectDrawCreateEx: 


HRESULT WINAPI DirectDrawCreateEx( 
GUID FAR *IpGUID, 
LPVOID *1р1ррр, 
REFIID iid, 
IUnknown FAR *pUnkOuter 
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T his returns an HRESULT, which is po. ok or some DDERR_* constant. T he parameters are explained in 
Table 5.1. 


Table 5.1 DirectDrawCreateEx Parameters 
DirectDrawCreateEx Parameter Purpose 


1pGUID A pointer to a GUID (globally unique identifier) 
that identifies the display drivers to use with the 
IDirectDraw7 object. 


Тртрор A pointer to your pointer to an IDirectDraw7 
interface. Must typecast to void**. 


iid An object type identifier. Must be set to 
IID IDirectDraw/. 


pUnkOuter COM aggregation stuff. Use NULL. 


T hese parameters are pretty Greek, so | think | have some explaining to do. A GUID (globally unique 
identifier) is how W indows identifies everything. Your video card has one, as do most of the rest of the 
pieces of hardware in your machine. А GUID allows you to identify any piece of hardware with one sim- 
ple (well, not exactly simple) numbering mechanism. You wont be doing too much with GU ID s, and you 
will be passing NULL when they are asked for. 


T he iid parameter is similar in function to a GUID — it's a class identifier. Each COM object 
(1DirectDraw7 induded) has a dass identifier; to make use of them, you must have dxguid.lib linked to 
your project under the Project, Settings tab. 


Confused? | was when I first laid eyes on this COM stuff. Allow me to show you the code for creating 
your IDirectDraw7 object: 


//create the direct draw interface 
HRESULT hr=DirectDrawCreateEx(NULL, (void**)&lpdd, I ID IDirectDraw7,NULL) ; 


U sually, the rule is as follows: if you dont know what the parameter is for or what its value should be, pass 
a NULL. 
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Наочт HRESULT 
I've mentioned HRESULTS twice up to this point— they're how D irectX NOTE 


returns error or success. U sually, when a function call returns and is This type of error 
successful, you get the value op. ox. If it fails, you get one of the many checking tends to clut- 
DDERR_* constants, indicating both that it failed and why it failed. ter up source code. For 
To test for this condition, M icrosoft has provided a macro called E кк: 
FAILED. TO check for errors, you do something like the following: TÉ 
//error check absolutely necessary. 


ifCFAILED(hr)) 
{ 


//there was an error 


} 


SETTING THE COOPERATIVE LEVEL 


After you have created your 1DirectDraw7 object, you need to specify the manner in which you want to 
use it. Essentially, there are two choices— windowed and full-screen. 


Select the manner in which you will use IdirectDraw7 through IDirectDraw7 5 SetCooperativeLevel 
member function: 


HRESULT SetCooperativeLevel ( 
HWND hWnd, 
DWORD dwFlags 

Jz 


Like all other D irectX functions, this returns error or success in an HRESULT. T he parameters are explained 
in Table 5.2. 


Table 5.2 SetCooperativeLevel Parameters 
SetC ooperativeLevel Parameter Purpose 


hWnd The top-level window that DirectDraw is to use 
dwFlags Cooperation flags (see Table 5.3) 
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T here are only about a handful of flags that you'll use with any frequency. T hey are listed in Table 5.3. 
M ost of the rest of the flags deal with multimon systems and D irect3D. 


Table 5.3 SetC ooperativeLevel Flags 
SetC ooperativeLevel Flag Meaning 


DDSCL_ALLOWREBOOT Allows an end user to use Ctrl+Alt+Delete during a full- 
screen application. This is a must if you intend to make 
W indows-friendly games. 


DDSCL_EXCLUSIVE Specifies that you want exclusive control over the display 
hardware.You must use DDSCL_FULLSCREEN also. 


DDSCL_FULLSCREEN Specifies that you want a full-screen application. Must be 
used with DDSCL_EXCLUSIVE. 


DDSCL_NORMAL Specifies that you are making a windowed application 
with D irectD raw. Useful for debugging. 


For the most part, you'll want to do full-screen, exclusive applications that have the ability to use 
Ctrl Alt- D dee so the code will look like this: 


//set cooperative level-fullscreen-exclusive 
hr-lpdd-»SetCooperativeLevel(hWndMain,DDSCL EXCLUSIVE | DDSCL FULLSCREEN | 
DDSCL ALLOWREBOOT) ; 


N ow that you have grabbed full-screen access to your display, you might want to change the display mode. 
You can do one of two things: one, you can start picking display modes from the commonly available ones 
until one works, or until none of them work, in which case youd be up a creek. O r two, you can enumer- 
ate the available display modes and then choose from that list. | prefer the latter method. Trial and error is 
not my style 


ENUMERATING DISPLAY MODES 


Enumeration of any type is a bit confusing at first. l'm not going to do anything really weird here. I’m just 
going to put the display modes into a пісе list that you can examine later in the code. 


First, let's go over the function you'll be calling to actually do the enumeration, EnumDi sp1ayModes: 


USING DiRecTORAW 


HRESULT EnumDisplayModes( 

DWORD dwFlags, 

LPDDSURFACEDESC2 lpDDSurfaceDesc?2, 

LPVOID lpContext, 

LPDDENUMMODESCALLBACK2 lpEnumModesCallback 
J; 


T his returns an HRESULT containing success or failure. Table 5.4 explains the parameter list. 


Table 5.4 EnumDisplayModes Parameters 
EnumDisplayModes Parameter Purpose 


dwFlags Special flags telling DD what kind of enumeration 
you want 

1pDDSurfaceDesc? A description of the type of display mode you are 
looking for 

lpContext A user-defined context variable that gets passed 


to the callback function 


1 pEnumModesCal 1Баск A pointer to the callback function 


T he dwF1ags parameter has two special values: DDEDM_REFRESHRATES, which takes into account the 
refresh rate for the display mode, and DDEDM_STANDARDVGAMODES, which enumerates the normal old VGA 
320х200х8 display mode. You wont use either of these flags; you will always pass 0. 


1pDDSurfaceDesc? is a pointer to a DDSURFACEDESC2 struct, which | will cover in more detail later in this 
chapter and in Chapter 6. If you were to set some of the members of a DDSURFACEDESC2 and then call the 
enumeration, you could filter your search. For now, you'll just list all of the display modes, and to heck 
with limiting the search. (You can look through them later after you've listed them all.) 


T he final parameter, 1 pEnumModesCallback, is а user-defined callback function, one that looks similar to 
the following: 


HRESULT WINAPI EnumModesCallback2( 
LPDDSURFACEDESC2 lpDDSurfaceDesc, 
LPVOID lpContext 
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T his function will return one of two values: DDENUMRET_OK will continue enumeration, and 
DDENUMRET_CANCEL Will stop it. 


1pDDSurfaceDesc is another pointer to DDSURFACEDESC2, which contains information about the display 
mode being enumerated. 1 pContext contains the value you originally passed in the call to 
EnumDisplayModes. 


T hereis a lot of information contained in a DDSURFACEDESC2 structure. H егес the definition: 


typedef struct  DDSURFACEDESC2 1 
DWORD dwSize; 
DWORD dwFlags; 
DWORD dwHeight; 
DWORD dwWidth; 
union 
{ 
LONG 1Pitch; 
DWORD dwLinearSize; 
} DUMMYUNIONNAMEN(1); 
DWORD dwBackBufferCount; 
union 
{ 
DWORD dwMipMapCount; 
DWORD dwRefreshRate; 
} DUMMYUNIONNAMEN(C2) ; 
DWORD dwAlphaBitDepth; 
DWORD dwReserved; 
LPVOID lpSurface; 
union 


{ 
DDCOLORKEY ddckCKDestOverlay; 
DWORD dwEmptyFaceColor; 
} DUMMYUNIONNAMEN(3) ; 
DDCOLORKEY ddckCKDestBlt; 
DDCOLORKEY ddckCKSrcOverlay; 
DDCOLORKEY ddckCKSrcBlt; 
DDPIXELFORMAT ddpfPixelFormat; 
DDSCAPS2 ddsCaps; 
DWORD dwlextureStage; 
} DDSURFACEDESC2, FAR* LPDDSURFACEDESC2; 


USING DiRecTORAW FEES 


As you can see, theres quite a bit here, and you will be using only a fraction of it. You'll be seeing DDSUR- 
FACEDESC2 іп more detail in Chapter 6. 


T he information you care about for a display mode consists of three things: the width, the height, and the 
color depth. | explained a bit about color depth in Chapter 2, "T heWorld of GDI and W indows 
Graphics,” during the discussion on pixel plotting. Briefly, color depth specifies how many bits each pixel 
contains. It usually has a value of 8, 16, 24, or 32. In depths higher than 8, the bits correspond to some 
RGB (red, green, blue) value that describes a color. 


In DDSURFACEDESC2, you can see the dwwidth and dwHeight members. T hese correspond to the size of 
the display mode (the resolution). Common values are 640х480, 800х600, and 1024x768. Some video 
cards can go even higher, and many video cards have more exotic display modes, like 400x300, 512x384, 
and so on. 


T he location of the bits per pixel is not quite as obvious in the DpSURFACEDESC2 structure, because it is 
part of the ddpfPixelFormat member, which is itself a ODPIXELFORMAT Structure. 


typedef struct _DDPIXELFORMAT { 
DWORD dwSize; 
DWORD dwFlags; 
DWORD dwFourCC; 
union 
{ 


DWORD 
DWORD 
DWORD 
DWORD 


wRGBBitCount; 

wYUVBitCount; 

wZBufferBitDepth; 

wAlphaBitDepth; 
DWORD dwLuminanceBitCount; 
DWORD dwBumpBitCount; 

} DUMMYUNTONNAMEN(1); 

union 


{ 


COL CL CL CL CL Су 


DWORD dwRBitMask; 
DWORD dwYBitMask; 
DWORD dwStencilBitDepth; 
d 
d 


DWORD dwLuminanceBitMask; 
DWORD dwBumpDuBitMask; 
} DUMMYUNIONNAMEN(2); 
union 


{ 


DWORD dwGBitMask; 
DWORD dwUBitMask; 
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DWORD dwZBitMask; 
DWORD dwBumpDvBitMask; 
} DUMMYUNIONNAMEN(3) ; 
unio 


{ 


DWORD dwBBitMask; 

DWORD dwVBitMask; 

DWORD dwStencilBitMask; 

DWORD dwBumpLuminanceBitMask; 
} DUMMYUNIONNAMEN(4) ; 

unio 
{ 
DWOR 
DWOR 


dwRGBAlphaBitMask; 
dwYUVAlphaBitMask; 
DWORD dwLuminanceAlphaBitMask; 
DWORD dwRGBZBitMask; 
DWORD dwYUVZBitMask; 

} DUMMYUNIONNAMEN(5); 
} DDPIXELFORMAT, FAR* LPDDPIXELFORMAT; 


D 
D 
D 
D 


T his is another big structure with a lot of information (but most of it is in the form of unions). Т his is 
your first look at DDPIXELFORMAT. It will be explored in more detail in Chapter 6, when we'll take a look 
at converting from one pixel format to another. T he member of DDPIXELFORMAT that concerns you is 
dwRGBBitCount, which contains the bit depth of the display mode (Seems like a whole lot of structure 
for just three little омовоз, doesnt it?) 


Let’s get enumerating, then. Enumerae twice: the first enumeration counts the display modes, and the sec- 
ond enumeration puts them into a list. 


First, define a structure that contains all the applicable information about a display mode (at least, as far as 
you're concerned): 


struct DisplayMode 

{ 
DWORD dwWidth; 
DWORD dwHeight; 
DWORD dwBPP; 


USING DIRECTORAW 


Short and sweet, the way things should ре, М ext, add two global variables: 


//the number of display modes will be kept here 
DWORD dwDisplayModeCount=0; 

//this will point to the list of display modes 
DisplayMode* DisplayModeList=NULL; 


T he first enumeration function is quite simple, since it just counts the display modes: 


HRESULT WINAPI EnumModesCallbackCount( 
LPDDSURFACEDESC2 lpDDSurfaceDesc, 
LPVOID IpContext 


//increment the count variable 
dwDisplayModeCount++; 
//continue the enumeration 
returnCDDENUMRET. OK) ; 


T he second enumeration isnt much more difficult: 


HRESULT WINAPI EnumModesCallbackList( 
LPDDSURFACEDESC2 lpDDSurfaceDesc, 
LPVOID IpContext 


//copy applicable information to the list 
DisplayModelList[dwDisplayModeCount ].dwWidth-lpDDSurfaceDesc-»dwWidth; 


DisplayModelList[dwDisplayModeCount ].dwHeight=1pDDSurfaceDesc->dwHeight; 


DisplayModelList[dwDisplayModeCount ].dwBPP-lpDDSurfaceDesc- 
»ddpfPixelFormat.dwRGBBitCount ; 
//increment the count variable 
dwDisplayModeCount++; 
//continue the enumeration 
return(DDENUMRET_OK) ; 


1-1 
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//C 
dwD 
//C 


Finally, put it all together to make the enumeration happen: 


lear the display mode count 
isplayModeCount-0; 
ount display modes 


lpdd-^EnumDisplayModes(O,NULL,NULL, EnumModesCallbackCount); 


//a 
Dis 
//r 
dwD 
А 


llocate space for the list 
playModeList=new DisplayMode[dwCount]; 
eset the count 

isplayModeCount=0 ; 

ist the display modes 


lpdd->EnumDisplayModes(0,NULL, NULL,EnumModesCallbackList); 


T he new operator performs about the same function as па11ос, only in a more typesafe way. T he malloc 
equivalent would һе: 


Dis 


playModeList=(DisplayMode*)malloc(sizeof(DisplayMode)*dwDisplayModeCount) ; 


W hen you are done with the list, use the following code to deallocate it: 


//d 
del 


elete the display mode list 
ete [] DisplayModeList; 


DisplayModeList=NULL; 


T his is equivalent to using the free function that is normally used with ma11oc. 


N ow you have all the possible display modes in a list, and you can loop through that list and test to see 
which mode you want. Also, you can look through to see if a given mode is supported. If it isnt, you can 
settle for а less-ideal mode. 


[ е5 do some code that checks for an 800x600x 16 mode (almost universally available). 


//set up the test mode 


Dis 
Tes 
Tes 
Tes 
//о 
boo 
//о 
DWO 
//w 
DWO 
for 
{ 


playMode TestMode; 

tMode.dwWidth-800; 

tMode.dwHeight-600; 

tMode.dwBPP-16; 

r boolean test variable 

1 found=false; 

r iterator 

RD index; 

here we found it (all bits set means not found) 
RD foundindex=OxFFFFFFFF; 
Cindex=0;(index<dwDisplayModeCount) && (!found);index++) 


USING DiRecTORAW 


if((DisplayModelist[index].dwWidth--TestMode.dwWidth) && 
(DisplayModeListLindex].dwHeight==TestMode.dwHeight) && 
(DisplayModeListLindex].dwBPP==TestMode.dwBPP) ) 


foundindex=index; 
found=true; 

} 

} 


Simple enough, right?You could perform a wide variety of tests on the display mode list, from finding the 
largest mode with a certain BPP to finding the greatest BPP for a given mode. Or, you might let the end 
user select what display mode he wants to run in, and save this value in a configuration file somewhere. 


N ow that you know what modes are available and what mode you want, you can use this information to 
set the display mode. (It's hard to believe that this topic took several pages to cover— the code gets execut- 
ed in a fraction of а second.) 


SETTING THE DISPLAY MODE 


After enumerating the display modes, setting the display mode is easy. You set the display mode with the 
SetDisplayMode member function of IDirectDraw7 (are you really surprised?). 


HRESULT SetDisplayMode( 
DWORD dwWidth, 
DWORD dwHeight, 
DWORD dwBPP, 
DWORD dwRefreshRate, 
DWORD dwFlags 

ju 


T his returns an HRESULT again (by now you should be spotting a pattern), and the parameters look suspi- 
ciously like the members of DisplayMode, with the exception of dwRefreshRate (which you dont саге 
about, so pass 0) and dwF1ags (which you also dont care about, so pass 0). 


Calling this function usually looks something like this: 


//set the display mode 
hr=1pdd->SetDisplayMode(800,600,16,0,0); 


Of course, the 800, 600, and 16 are whatever display mode you want, or variables containing the values 
you want. 
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RETRIEVING THE CURRENT DISPLAY 
MODE 


Of course, there may be times when you want to retrieve the current display mode. To do this, you use 
GetDisplayMode. 


HRESULT GetDisplayMode( 
LPDDSURFACEDESC2 lpDDSurfaceDesc2 
J5 


Look! It returns an HRESULT! (I'm not going to mention the return values for ох functions anymore. T hey 
are all HRESULTS and are all treated exactly the same way.) 


T he sole parameter of this function is 1pDDSurfaceDesc2, which is a pointer to a DDSURFACEDESC2. 
Declare a variable of DDSURFACEDESC2, dean it out, and call the function. W hen it returns, your DDSUR- 
FACEDESC2 Contains the information describing the current display mode (similar to how it did when you 
enumerated display modes). But what do | mean by “cleaning out" а DDSURFACEDESC2?Well, in most 
cases, when you work with DDSURFACEDESC2S, or any other DirectX structure, you first have to initialize it 
(set all members to 0), and you have to set the dusize member. T his is how to do so: 


//declare the variable 

DDSURFACEDESC2 ddsd; 

//initialize to all zeros 

memset (&ddsd,0,sizeof(DDSURFACEDESC2) ); 
//set the size 
ddsd.dwSizeesizeof(DDSURFACEDESC2) ; 


After it has been cleaned out, it is ready to use 


//retrieve the display mode 
hr=lpdd->GetDisplayMode(&ddsd) ; 


Just like within the enumeration function, the width and height of the display mode are stored in 
ddsd.dwWidth and ddsd.dwHeight, and the bits per pixel are stored in 
ddsd.ddpfPixelFormat.dwRGBBitCount. 


USING DiRecTORAW 


A FINAL THING! RELEASING OBJECTS 
T here is a certain way in which you delete almost all DirectX objects once you are done with them. For 
your 1pdd, this is what it looks like: 


if (1pdd) 
{ 


lpdd->Release(); 
1pdd-NULL; 
} 


T his exact same snippet, with just a different variable, will be used for most of your DirectX cleanup. Just 
as it was important during GDI to get rid of your object and DCs, it is also important to get rid of your 
DirectX object. 


Check out 150Н ех5 1.cpp (the only Chapter 5 example), and see in action what | have been talking about 
here. D ont expect much; you'll just end up with a black screen. H owever, now that you are into D irectX , 
that screen is yours! 


SUMMARY 


T his chapter has given you entry to the world of DirectD raw, but so far you've only got your foot in the 
door. Н ere are some key points to remember: 


= The IDirectDraw7 object controls display resources. It is the parent of all other DirectDraw objects. You 
create one with Di rectDrawCreateEx. 

= Depending on what you want to use the IDirectDraw7 object for, you must set an appropriate cooperative 
level using SetCooperativeLevel. 

= Although there are display modes that are widely supported on most video cards, it's still a good idea to enu- 
merate the display modes before selecting the one you want to use. 
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ow were getting into some cool stuff: D irectD raw surfaces (the IDirectDrawSurface7 Object). 

Surfaces are D irectD raw's stock in trade. T hey hold graphical images that you can display and 
manipulate, similar in function to memory device contexts but without all the abstraction inherent to GDI. 
Of course, you can still use GD! functions with your surfaces, as you'll see a little later. T his is a big chap- 
ter, апа we've got alot of ground to cover, so let's get going. 


WHAT 15 A SURFACE? 


Quite simply, a surface is a block of memory (either on your video card or in system memory) that is man- 
aged by D irectD raw as though it were a rectangle, even though the memory itself is linear. Surfaces come 
in many types. T he difference between these types lies in what each surface is capable of. T he three types of 
surfaces that you will be concerned with at this point are primary surfaces, secondary surfaces (back 
buffers), and off-screen surfaces. 


» Primary Surface. [п any application, you will have only one primary surface for each D irectD raw object. (In a 
multiple-monitor system, with multiple D irectD raw interfaces, it is possible to have more than one) T he pri- 
mary surface is the only surface in D irectD raw that is visible. 

= Secondary Surfaces. A secondary surface, or back buffer, is not a surface all on its own. N ot quite. Sure, you 
can still do all the things with a secondary surface that you can do with any other type of surface, but the 
existence of a secondary surface depends on other surfaces. It is attached to another surface and is part of 
what is called a flipping chain. M ore about this a little later. 

= Off-Screen Surfaces. An off-screen surface is what you will use to store your bitmaps and other graphical 
data until it is needed. Q uite often you'll have а large number of these, and many of them will be small in 
size. T hey serve about the same function as do memory D Cs. 


N ow that you've been introduced to surfaces, let's start making them! 


CREATING A SURFACE 


All surfaces (except secondary surfaces) start out their life with a call to IDirectDraw7'S CreateSurface. 


HRESULT CreateSurface( 
LPDDSURFACEDESC2 lpDDSurfaceDesc?2, 
LPDIRECTDRAWSURFACE7 FAR *lplpDDSurface, 
IUnknown FAR *pUnkOuter 

); 
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Оп success, this returns ор_ок. Table 6.1 explains the parameter list. 


Table 6.1 IDirectDraw7::CreateSurface Parameters 

CreateSurface Parameter Purpose 

1 pDDSurfaceDesc2 Pointer to a DDSURFACEDESC? containing a description of 
the desired surface 


lplpDDSurface Pointer to an LPDIRECTDRAWSURFACE7 pointer that will 
be filled with a pointer to the new 
IDirectDrawSurface7 object 


pUnkOuter COM stuff. Use NULL. 


DOSURFACEDESCr 


N ow I’m going to go into alittle more detail about DDSURFACEDESC2, which was introduced in Chapter 5, 
“U sing D irectD raw." 


H егес the structure again, with the important fields highlighted in bold: 
typedef struct _DDSURFACEDESC2 { 


DWORD dwSize; 
DWORD dwFlags; 
DWORD dwHeight; 
DWORD dwWidth; 
union 
{ 
LONG lPitch; 
DWORD dwLinearSize; 
} DUMMYUNIONNAMEN(CI1); 
DWORD dwBackBufferCount; 
union 
{ 
DWORD dwMipMapCount; 
DWORD dwRefreshRate; 


} DUMMYUNTONNAMEN(2); 
DWORD dwAlphaBitDepth; 
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DWORD dwReserved; 
LPVOID lpSurface; 
union 


{ 
DDCOLORKEY ddckCKDestOverlay; 
DWORD dwEmptyFaceColor; 
| DUMMYUNIONNAMEN(3) ; 
DDCOLORKEY ddckCKDestBlt; 
DDCOLORKEY ddckCKSrcOverlay; 
DDCOLORKEY ddckCKSrcBlt; 
DDPIXELFORMAT ddpfPixel Format; 
DDSCAPS2 ddsCaps; 
DWORD dwTextureStage; 
} DDSURFACEDESC2, FAR* LPDDSURFACEDESC2; 


T he highlighted fields are explained in Table 6.2. 


Table 6.2 Meaningful Members of DDSUFACEDESC2 
DDSURFACEDESC2 Member Meaning 


dwSize The size of the DDSURFACEDESC2.A ways set to 
sizeof(DDSURFACEDESC2). 

dwFlags Flags specifying which of the other members are 
meaningful (see the next section) 

dwHei ght Height of a surface 

dwWidth W idth of a surface 

lPitch The pitch of a surface (discussed later, in the section 
"The Nitty-Gritty: Lock and Unlock") 

dwBackBufferCount The number of back buffers that a surface has. U sed 
when creating complex surfaces. 

lpSurface A pointer to the surface’s memory (discussed in the 
section "The N itty-Gritty: Lock and Unlock") 

ddpfPixelFormat The pixel format of the surface (discussed in more 
detail later) 

ddsCaps The capabilities of the surface (discussed in 


a moment) 
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Н opefully, this has made oDSuRFACEDESC2 just a little less scary. М ost of the rest of this stuff is for 
advanced use, and much of it isnt even implemented yet. 


DWFLAGS 
T he awF1ags member specifies what other members are valid. Various flags are shown in Table 6.3. 


Table 6.3 DDSURFACEDESC2 Flags 
DDSURFACEDESC2 Flag Member Validated 


DDSD HEIGHT dwHeight 

DDSD. WIDTH dwWidth 

DDSD. PITCH 1Pitch 

DDSD_BACKBUFFERCOUNT dwBackBufferCount 

DDSD PIXELFORMAT ddpfPixelFormat 

DDSD. CAPS ddsCaps 
DDSCAPS 


W hen creating a surface, always use the ddsCaps member to specify what kind of surface you want. 
ddsCaps 15 іп itself a structure, а DDSCAPS2. 


typedef struct _DDSCAPS2 { 
DWORD dwCaps; 
DWORD dwCaps2; 
DWORD dwCaps3; 
DWORD dwCaps4; 
} DDSCAPS2, FAR* LPDDSCAPS2; 


All the members of this structure contain flags. N either dwCaps3 пог dwCaps4 is currently used. T he 
dwCaps2 member is for advanced stuff dealing with D 3D, so the only one you need to be concerned with 
iS dwCaps, which contains a number of flags that you will find useful. Some of these flags are listed in 
Table 6.4. 
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Table 6.4 Selected DDSCAPS2 Flags 


dwCaps Flag Use 
DDSCAPS BACKBUFFER 


DDSCAPS COMPLEX 
attached 


DDSCAPS_FLIP 
attached 


DDSCAPS_OFFSCREENPLAIN 
DDSCAPS_PRIMARY SURFACE 
DDSCAPS_SYSTEMMEMORY 


DDSCAPS VIDEOMEMORY 


Creates a secondary surface 
Creates a primary surface that has a secondary surface 


Creates a primary surface that has a secondary surface 


Creates an off-screen surface 
Creates a primary surface 
Creates a surface in system memory 


Creates a surface in video memory 


T here are quite a few more flags, but you wont be using them. 


CREATING A 
PRIMARY SURFACE 
T he first surface you create in a D irectD raw 
application is the primary surface Т hen you 
fetch the back buffers (if any), and then you 
start making the off-screen surfaces. 

At some point, usually in the globals section, 
you should declare a variable that will contain a 
pointer to the primary surface 


//primary surface 


LPDIRECTDRAWSURFACE7 lpddsPrime-NULL; 


NOTE 


Your video card has only a limited amount of 
memory.The primary surface (and any back 
buffers for the primary) must be in video 
memory. Off-screen surfaces have greater 
performance if they are in video memory, 
but they can be in system memory as well— 


though you'll feel a performance hit. 


Always create your surfaces in decreasing 
order of importance. If it is an oft-used sur- 
face—like the bitmap containing the main 
character—create it sooner than the sur- 
faces that contain the graphics for the title 
screen (the title screen doesn't need to be as 
fast as the game itself). 
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First, set up your surface description: 


//clean out surface description 
DDSURFACEDESC2 ddsd; 

memset (&ddsd,0,sizeof(DDSURFACEDESC2) ) ; 
ddsd.dwSize=sizeof (DDSURFACEDESC2) ; 
//set up the caps for the primary 
ddsd.dwFlags=DDSD_CAPS; 
ddsd.ddsCaps.dwCaps-DDSCAPS PRIMARYSURFACE ; 
//finally, create the surface 
lpdd-»CreateSurface(&ddsd,&lpddsPrime,NULL) ; 


And later, when you are dosing the program and cleaning up, do a safe release of the primary surface 
(which looks almost exactly like the safe release of the IDirectDraw7 object): 


if(lpddsPrime) 

{ 
lpddsPrime->Release(); 
lpddsPrime=NULL; 


CREATING A SECONDARY SuRFACE/S 
BACK BUFFER 


Create back buffers, if you will have them, at the same time you create your primary surface. W hen you 
create your primary surface, specify that it is a complex surface that can be flipped, and specify how many 
back buffers it will have. (ГП discuss flipping in a moment.) 


//surfaces 

LPDIRECTDRAWSURFACE7 lpddsPrime-NULL; 
LPDIRECTDRAWSURFACE7 lpddsBack-NULL; 

//clean out surface description 

DDSURFACEDESC2 ddsd; 

memset (&ddsd,0,sizeof(DDSURFACEDESC2) ) ; 
ddsd.dwSize=sizeof (DDSURFACEDESC2) ; 

//set up the caps for the primary 
ddsd.dwFlags=DDSD_CAPS | DDSD_BACKBUFFERCOUNT; 
ddsd.dwBackBufferCount=1; 
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ddsd.ddsCaps.dwCaps=DDSCAPS_PRIMARYSURFACE | DDSCAPS_COMPLEX | DDSCAPS_FLIP; 
//finally, create the surface 
lpdd-»CreateSurface(&ddsd,&lpddsPrime,NULL) ; 


№ ow you've got the primary surface, which has the secondary surface attached to it. To retrieve this 
attached surface, use GetAttachedSurface: 


HRESULT GetAttachedSurface( 

LPDDSCAPS2 lpDDSCaps, 

LPDIRECTDRAWSURFACE7 FAR *IpipDDAttachedSurface 
$ 


T his function takes a pointer to а 005САР52 structure, specifying the capabilities of the attached surface, 
and a pointer to an LPDIRECTDRAWSURFACE7, which will be filled with a pointer to the attached surface. 


So, to retrieve the back buffer: 


//clean out a DDSCAPS2 

DDSCAPS2 ddsCaps; 

memset (&ddsCaps,0,sizeof(DDSCAPS2)); 

//specify that we want a back buffer 
ddsCaps.dwCaps=DDSCAPS_BACKBUFFER; 

//retrieve the back buffer 
lpddsPrime-»GetAttachedSurface(&ddsCaps,&lpddsBack); 


Мну Мек BACK BUFFERS? 


You ould just write to the primary surface. You really could. Н owever, there would be detrimental effects. 
T he user would see items as they were being drawn to the screen, and if the drawing was not timed cor- 
rectly, shearing would occur as the electron gun in the back of the monitor misses some of the informa- 
tion you placed on the primary surface T his creates a flickering effect, and in general is not considered 
good practice. 


To make everything look as good as possible, it's a wise idea to make both a primary surface, which is 
shown to the user at all times, and attach to it a back buffer/ secondary surface. D oing so makes the sur- 
faces similar to a flip book; in fact, switching which surface is the primary and which is the back buffer is 
called flipping, and the two surfaces are called a flipping dain. You dont have to do anything special once 
you've flipped the primary surface. D irectD raw is smart enough to know how to exchange the memory of 
the two surfaces. You can do all your writing to a back buffer and then use ЕТ ip, which switches the 
memory from the back to the primary. D irectD raw takes care of timing it correctly. And miraculously, you 
will have no flicker. 
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FLIPPING 
Т he Flip function looks like this: 


HRESULT IDirectDrawSurface7::Flipt( 
LPDIRECTDRAWSURFACE7 lpDDSurfaceTargetOverride, 
DWORD dwFlags 


1pDDSurfaceTargetOverride [5 for use with advanced flipping chains, and you'll just pass NULL. T he 
dwFlags parameter, however, can be useful. You will be placing the constant DoFLIP_WAIT into this 
parameter. T his allows D irectD raw to time the transfer properly so that no flickering or shearing occurs. 


О ne last thing about back buffers before we move on: you dont have to do a release of the back buffer— 
that's taken care of when the primary surface is released. 


OFF-ScREEN SURFACES 


T he final type of surface that you'll be dealing with (at least, until you get into D 3D later in this book) is 
the off-screen surface. An off-screen surface can exist in either system memory or video memory. If you do 
not specify either of these іп the ааѕсарѕ member of ооѕикғАСЕрЕЅС2, DirectD raw will try to put it into 
video memory, and if that fails, it will place the surface in system memory. 


Remember what | said earlier about the location of surfaces; make your most commonly used off-screen 
surfaces in video memory if you can, and resort to system memory if you have to. 


Following is an example of creating an off-screen surface, trying first for video memory and then falling 
back to surface memory. N ote that you set the dwwidth, dwHeight, and ddsCaps part of the DDSUR- 
FACEDESC? Structure. 


//declaration (global) 
LPDIRECTDRAWSURFACE7 lpddsOffScrn=NULL; 
//set up the DDSURFACEDESC2 
DDSURFACEDESC2 ddsd; 
emset(&ddsd,0,sizeof(DDSURFACEDESC2)); 
dsd.dwSize=sizeof(DDSURFACEDESC2) ; 

/set flags... width, height, caps 

dsd.dwFlags-DDSD WIDTH | DDSD HEIGHT | DDSD CAPS; 

/attempt video memory 

sd.ddsCaps.dwCaps-DDSCAPS OFFSCREENPLAIN | DDSCAPS VIDEOMEMORY ; 
/width and height=100x100 

dsd.dwWidth-100; 

dsd.dwHeight=100; 

RESULT hr=lpdd->CreateSurface(&ddsd,&lpddsOffScrn,NULL); 
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if (FAILED(hr) ) 
{ 
//not enough video memory, try system memory 
ddsd.ddsCaps.dwCaps=DDSCAPS_OFFSCREENPLAIN | DDSCAPS_SYSTEMMEMORY ; 
//try agai 
hr=lpdd->CreateSurface(&ddsd,&lpddsOffScrn, NULL); 
if (FAILED(hr) ) 
{ 


//something still went wrong... 


USING SURFACES 


N ow that you know how to make surfaces, you can get down to the very serious business of using them. 
T his section outlines the various ways in which you can write to and read from surfaces and copy them to 
one another. 


GeTOC/RELEASEDC, OR USING GD1 ом 
SURFACES 


Just because you arein DirectX doesnt mean that you have to leave СІ behind. Admittedly, using GDI 
in atime-critical section isnt the best idea, but for loading bitmaps and placing them on surfaces, GDI will 
do just fine 


[п order to perform 601 functions on a surface, you need an нос. Luckily, there is a function that does 
just that: 1DirectDrawSurface7::GetDC 


HRESULT IDirectDrawSurface7::GetDC( 
HDC FAR *1phDC 
DE: 


To make use of this function, you send a pointer to an нос to it, like so: 


//grab the dc from the surface 
HDC hdcSurf; 
lpddsPrime-»GetDC(&hdcSurf); 
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If successful, hdcSurf will now contain а GDI-compatible device context. Pretty cool. 
W hen you are done using the DC, be sure to release it with 1DirectDrawSurface7: :ReleaseDC. 


//release the dc 
lpddsPrime-»ReleaseDC(hdcSurf); 


CAUTION 


If you don't release the DC, your computer is very, very likely to lock 
up (and there's no Ctrl+Alt+Delete to save you). Also, between the 
calls to GetDC and ReleaseDC, your computer's display will be frozen, so 
don't keep the DC any longer than you have to. Just get in, get it done, 
and get out. 


Enough of this talk! Let's do an example. Load up 150Н ex6_ 1.срр. You will also need your trusty 
GD ICanvas.h and GD ICanvas.cpp files, and 150Н ex6_ 1.bmp. 


IsoH ex6_ 1.cpp was built from IsoH ex5_ 1.cpp, with some extra stuff that weve covered this chapter. If 
you run it, you'll see a lazy ball that slowly meanders around the screen, bouncing off the walls, as shown 
in Figure 6.1. 


Figure 6.1 


The bouncing ball demo 


You'll notice that the movement is slow, but smooth. T his is partly because of GDI and partly because of 


SURFACES 


my clearing the back buffer each time Prog. Loop is called. 


N otice, though, in Prog. Loop, how | dont mess around too much between the calls to Getbc and 
ReleaseDC. | set up the filling RECT before! get there, and | take care of other stuff after I’m done. 


void Prog Loop() 


{ 


//set up rectangle for filling 
ВЕСТ ТЕРІІІЗ 
SetRect(&rcFill,0,0,dwDisplayWidth,dwDisplayHeight); 
//grab dc from back buffer 

HDC hdcSurf; 
lpddsBack-»GetDC(&hdcSurf); 

//fill rectangle with black 
FillRect(hdcSurf,&rcFill,(HBRUSH)GetStockObject(BLACK BRUSH)); 
//show the ball 
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BitBlt(hdcSurf,ptBallPosition.x,ptBallPosition.y,gdicBall.GetWidth(),gdicBall.Get 
Height(),gdicBall,0,0, SRCCOPY); 
//release dc 
lpddsBack-»ReleaseDC(hdcSurf); 
//move the ball 
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Т he code in bold is what is between Getoc and кет еаѕерс, inclusive. | put absolutely nothing extraneous in 
that section. In reality, | shouldnt even have the function call to Getstockobject in there (heck, | even 
shouldnt be using GDI to do this, but this is an example). 


So, we have now created a screen saver— a terribly slow screen saver. If you want to see why you should use 
back buffers, comment out the line with тір in it, and then change GetDc and ветеазе0С to get and 
release from the primary surface. O r, if you're too lazy to do that, replace IsoH ex6_ 1.cpp with 

IsoH 6 1A .cpp, where! did it for you. Running it again, you'll see how badly the ball flickers. М ow 
imagine this happening with six or eight characters on the screen. Blech! And the defense rests. You're 
probably thinking that there has to be a better way, right? Of course there is. 


ELT 


T he 1DirectDrawSurface7::B1t function is the D irectD raw ver- 
sion of 6015 gitgit, but it's faster. T he reason it's faster is 

because D irectD raw doesnt give you a safety net like GDI does. NOTE 
In GDI, if oneDC has a different pixel format than another, 


GDI converts it for you. T his, of course, takes time, especially таме астей 
when the pixel formats аге wildly different. "eis gue de (ргы, 
D irectD raw wont help you at all with pixel format conversion. It call to CreateSurface isnot 
expects that both the source and destination have the same pixel exactly true. However, for 
format, and if they dont, you'll get garbage on the screen. our purposes it is true 
Luckily, every surface created from a call to enough, since we aren't deal- 
IDirectDraw7::CreateSurface has the same pixel format, SO ing with any sort of special- 


you only have to worry about pixel format conversion once, when ized surface types. 
you first load the bitmap onto a surface. In your case, this wont be 


too much of a problem because you'll use GDI to load the bitmap for you. 


B1t also allows you to fill a rectangular area with a solid color, much in the same way ri11Rect does, but 
faster. You can stretch an image using вт+, and if the hardware acceleration is available you can even rotate 
it. You can also make use of a clipper when using вт, but well get to clippers later. 


For even less of a safety net, you can use 81+'S faster cousin, B1tFast. В1%Ға5% is the fastest way that is 
supported by D irectD raw (it is possible to get faster using Lock/ Unlock) to copy a rectangular image 
from one surface to another. N o stretching, no clipping, no nothing. Any computations you need to do to 
make it work right are your problem. 


SURFACES ЕСЕЙ 


H eres the IDirectDrawSurface7::B1t function: 


HRESULT IDirectDrawSurface7::Blt( 
LPRECT lpDestRect, 
LPDIRECTDRAWSURFACE7 lpDDSrcSurface, 
LPRECT lpSrcRect, 

DWORD dwFlags, 
LPDDBLTFX IpDDBltFx 


T he parameters mirror somewhat the parameters of git81t. T his returns 00. ok if successful. Table 6.5 
explains the parameters. 


Table 65 IDirectDrawSurface7::Blt Parameters 
Blt Parameter Purpose 


lpDestRect The destination rectangle. NULL is the entire surface. 
1pDDSrcSurface The source surface. NULL if not applicable. 


lpSrcRect The source rectangle. NULL if not applicable or the entire surface. 
dwFlags Flags specifying how you want the 81t to work 
1pDDBltFx A pointer to a DDBLTFX structure, with extra information about 


how the B1t is supposed to work. Used in conjunction with the 
dwFlags parameter. 


Table 6.6 lists a handful of meaningful flags that can be passed in the awF1ags parameter— well, the flags 
that are meaningful to you, anyway. 


160 | ISOMETRIC GAME PROGRAMMING WITH, DIRECTX 7,0 


Table 6.6 Selected ВК Flags 


Bit Flag Meaning 

DDBLT_COLORFILL This B1t is a color fill operation. This requries a non-null 1pDDB1tFx. 

DDBLT_KEYSRC This 81% is a partially transparent 81% (we'll check out color keys а 
bit later) 

DDBLT_WAIT The blitter (the hardware that performs blitting on the video card) 
must wait until the B1t is finished before returning 

DDBLT. КОР This B1t makes use of a raster operation (like SRCAND, SRCPAINT, and 
SO on) 


THE DDBLTFX STRUCTURE 


T he орвітех structure is another one that's like DDSURFACEDESC2, meaning it has a lot of useless mem- 
bers that either havent been implemented yet or are never going to be implemented. Н егес the structure, 
with the important members in bold: 


typedef struct _DDBLTFX{ 
DWORD dwSize; 

ORD dwDDFX; 

ORD dwROP; 

dwDDROP; 
dwRotationAngle; 
dwZBufferOpCode; 
dwZBufferLow; 
dwZBufferHigh; 
dwZBufferBaseDest; 
dwZDestConstBitDepth; 
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DWORD dwZDestConst; 
LPDIRECTDRAWSURFACE lpDDSZBufferDest; 
} DUMMYUNIONNAMEN( 1); 
DWORD dwZSrcConstBitDepth; 
union 
{ 
DWORD dwZSrcConst; 
LPDIRECTDRAWSURFACE 1lpDDSZBufferSrc; 
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} DUMMYUNTONNAMEN(2); 

DWORD dwAlphaEdgeBlendBitDepth; 
DWORD dwAlphaEdgeBlend; 

DWORD dwReserved; 

DWORD dwAlphaDestConstBitDepth; 


union 

{ 
DWORD dwAlphaDestConst; 
LPDIRECTDRAWSURFACE IpDDSAlphaDest; 

} DUMMYUNTONNAMEN(3) ; 

DWORD dwAlphaSrcConstBitDepth; 

union 

{ 
DWORD dwAlphaSrcConst; 
LPDIRECTDRAWSURFACE IpDDSAlphaSrc; 

} DUMMYUNIONNAMEN(A4) ; 

union 

{ 
DWORD dwFillColor; 
DWORD dwFillDepth; 
DWORD dwFillPixel; 
LPDIRECTDRAWSURFACE lpDDSPattern; 

} DUMMYUNIONNAMEN(5) ; 


DDCOLORKEY ddckDestColorkey; 
DDCOLORKEY ddckSrcColorkey; 
) DDBLTFX,FAR* LPDDBLTFX; 


See what | mean?T hat's һис And only three of the members have any meaning to you (not to say that 
none of the others are meaningful). 


MAKING USE or A DDBLTFX 


М uch like a DDSURFACEDESC2, a DDBLTFX structure must first be cleared out, and the dwSize field has to 
be set, like so: 


//clear our DDBLTFX 

DDBLTFX ddbltfx; 
memset(&ddbltfx,O,sizeof(DDBLTFX)) ; 
ddbltfx.dwSize-esizeof(DDBLTFX); 
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And to do a color fill, you set the dwFi11Color field: 


//set fill color 
ddbltfx.dwFillColor=0;//zero is black 


N ow all you need is a destination rectangle, or can just use NULL if filling the entire surface. 


RECT rcFill; 

SetRect(0,0,dwDisplayWidth,dwDisplayHeight); 
lpddsBack-»Blt(&rcFill,NULL,NULL,DDBLT WAIT | DDBLT FILLCOLOR, &ddbltfx); 
or 


lpddsBack-»Blt(NULL,NULL,NULL,DDBLT WAIT | DDBLT FILLCOLOR, &ddbltfx); 


T his solves your call to Fi11Rect. You'll no longer need it. 


USING BLT TO Cory FROM SURFACE TO SURFACE 


Just doing a straight copy is no big deal. You dont need a ооветЕх, and the only flag you need is 
DDBLT_WAIT. Other than that, it’s just a matter of setting up the source and destination RECTS, like 50: 


RECT rcDst; 
RECT rcSrc; 
SetRect(&rcDst,DstX,DstY, DstX+DstWidth, DstY+DstHeight); 
SetRect(&rcSrc,SrcX,SrcY, Srex+SrcWidth, SrcY+SrcHeight); 


Keep in mind, however, that if the вЕСТ$ have differing widths, you will have stretching, and unless there is 
hardware support for stretching, the software emulation wont be that great quality-wise. 


Let's revise our little bouncing ball demo. Load up IsoH ex6 2.cpp. T he first thing | want to point out is 
that this example makes an additional surface, an off-screen surface called 1pdasBa11, onto which you 
load the picture of the ball. 


//create an offscreen surface to contain the ball 
//clear out ddsd 
emset(&ddsd,0,sizeof(DDSURFACEDESC2)); 
ddsd.dwSize-sizeof(DDSURFACEDESC2) ; 

//set ddsd flags 

ddsd.dwFlags-DDSD WIDTH | DDSD HEIGHT | DDSD CAPS; 
//set width and height 
ddsd.dwWidthegdicBall.GetWidth(); 
ddsd.dwHeightegdicBall.GetHeight(); 

//set caps 

ddsd.ddsCaps.dwCaps-DDSCAPS OFFSCREENPLAIN; 
//create surface 
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lpdd-»CreateSurface(&ddsd,&lpddsBall,NULL) ; 
//grab dc from offscreen surface 

HDC hdcSurf; 
lpddsBall-»GetDC(&hdcSurf); 

//blit ball to surface 
BitBlt(hdcSurf,0,0,gdicBall.GetWidth(),gdicBall.GetHeight(),gdicBall,0,0,SRC- 
COPY); 
//release dc 
lpddsBall-»ReleaseDC(hdcSurf); 


N otice that you аге still using CaDICanvas to load in your bitmap, and are using Get DC/ ReleaseDC and 
BitB1t to get the image onto the surface. 


Also, take note of the use of the ptLastPosition variable, an array of two Po1NTS. W hen moving the 
ball around in Prog. Loop, you dear out only the section of the screen that contained the ball two frames 
ago. W hy two frames? Because there are two calls to Flip between the time a ball is shown and the time it 
is erased. 


Confused? L et me explain. L et’s say that the ball is moving 4 horizonal and 4 vertical pixels per frame. On 
the first frame (when there is still nothing on the primary surface), the ball's upper-left corner is at 0,0, 
where it gets drawn to the back buffer, and then the surfaces get flipped, and the ball shows up at 0,0 on 
the primary surface. N ow the ball is at 4,4, gets drawn there, and gets flipped again. T he ball image on the 
primary surface is at (4,4), and on the back buffer you have an image of the ball at (0,0) — the image of 
two frames ago. So, you erase the old image at (0,0) and draw a new one at (8,8) and flip it again. On the 
primary you now have it at (8,8) and on the back buffer at (4,4). See? 


In a more complicated program (with a more complicated background, like a terrain map or something), 
you would probably be best served by copying the primary to the back buffer before restoring the old 
images (this way you'd have to keep track of only a single "last position"). For this example | wanted to 
make the program do as little work as possible. 


N ow that you are using 81t, the example is even smoother than the version that used GD 1— so much 
smoother that | increased the speed by 4, and you dont even notice. If you look at the code, you'll see a 
lot of ugly stuff— all the clearings of DDSURFACEDESC2S and DDBLTFXS and the setting up of these struc- 
tures. W еге going to wrap these repetitive tasks into functions in just a bit. 


COLOR KEYING WITH BLT 

One of the best parts of using вт+ is the ability to make part of the image transparent by using a color 
key. To examine why having transparent pixels is important, take a look at 150Н ехб 3.cpp. T his example is 
an enhanced |soH ехб 2.cpp. T he main difference is that there are now two balls instead of just one. 
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Watch closely as the program runs. W hen the balls are very close to one another, their rectangles overlap, 
as shown in Figure 6.2. 


Figure 6.2 


Overlapping rectangles; one 
ball erases part of another 


T his, as l'm sure you'll agree, is not good. In GD уои would use a bitmask, and you could do the same 
thing in D irectD raw, using the амкор member of ров! ТЕХ. Support for dwRop is Spotty, so we wont use 
it. H owever, D irectD raw gives us an easier solution. 


T hereare two types of color keys— source and destination. W ith source color keying, you apply your key to 
the source, and then a color (or range of colors) of one surface is ignored when blitting to another surface. 
D exination color keying is different. It requires hardware support and is usually used only with video signals 
and the like, so I’m not going to cover it here. 


То set a color key, you need to fill out a оосоговкЕУ structure 


typedef struct _DDCOLORKEY { 
DWORD dwColorSpaceLowValue; 
DWORD dwColorSpaceHighValue; 

} DDCOLORKEY,FAR* LPDDCOLORKEY ; 


You may be pleasantly surprised to find DirectX has a structure that isnt as bloated as some others you've 
seen (like DDSURFACEDESC2 and DDBLTFX). 


T here are two values in a DDCOLORKEY— alow and a high color value. Т his is in case you want to define а 
color space (a range of colors) and thus have more than one transparent color. D oing so requires hardware 
support, and the hardware support available for it is spotty, so try to get along with having only a single 
transparent color. 


SURFACES 165 | 


Setting up а DDCOLORKEY Is pretty simple: 


//set up a black color key 
DDCOLORKEY ddck; 
ddck.dwColorSpaceLowValue=0; 
ddck.dwColorSpaceHighValue=0; 


To set a surfaces color key, you use IDirectDrawSurface7::SetColorKey: 


HRESULT IDirectDrawSurface7::SetColorKey( 
DWORD dwFlags, 
LPDDCOLORKEY lpDDColorKey 

у; 


T he dur1ags parameter contains the type of color key you are assigning, which in this case will always be 
DDCKEY_SRCBLT. O ther possible values include DDCKEY_DESTBLT, DDCKEY_SRCOVERLAY, 
DDCKEY_DESTOVERLAY, and combining any of these with DocKEY_COLORSPACE (most of these require 
some sort of hardware support). So, setting the color key is pretty simple 


//assign color key 

lpddsBall-»SetColorKey(DDCKEY SRCBLT,&ddck); 

Finally, to make use of the color key, you add a DDBLT_KEYSRC to your 81% function: 
lpddsBack-»Blt(&rcDst,lpddsBall,&rcSrc,DDBLT WAIT | DDBLT KEYSRC, NULL); 


Т helsoH ex6_ 3A.cpp example demonstrates this. Four lines of code were added, and one line of code was 
modified. T he overlapping rectangle problem is gone, as you can see in Figure 6.3. 


Figure 6.3 
Source color keying 
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You could now have 100 balls on the screen bouncing around, and it would still be smooth and look right. 


BLTFAST 


Let me introduce you to в1:5 brother, B1tFast. B1tFast is іп most cases a lot faster than 81%, because it 
doesnt do any range checking if theres a clipper involved. It also doesnt do stretching, color fills, or raster 
operations. In general, it doesnt give you any of the neat things that вт can give you, except for trans- 
parency. 


HRESULT IDirectDrawSurface7::BltFast( 
DWORD dwX, 
DWORD dwY, 
LPDIRECTDRAWSURFACE7 lpDDSrcSurface, 
LPRECT lpSrcRect, 
DWORD dwTrans 

); 


T his returns po ox if successful. Table 6.7 explains the parameters. 


Table 6.7 |IDirectDrawSurface7::BitFast Parameters 
BitFast Parameter Purpose 


dwX Destination x-coordinate (upper-left) 
dwY Destination y-coordinate (upper-left) 
1pDDSrcSurface Source surface 

IpSrcRect Source rectangle 

dwTrans Type of transfer 


M ost of the parameters for 81% and B1tFast аге the same T here is only a single RECT parameter, however, 
because B1tFast does not support scaling. Also, you'll note a lack of a DDBLTFx pointer. N one of the spe 
cial effects possible with ров! тех are available to you with B1tFast. 


T he awrrans parameter is similar to в1+5 dwFlags parameter, but with fewer options: 
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= DDBLTFAST DESTCOLORKEY Uses the destination surface's destination color key 
= DDBLTFAST NOCOLORKEY Uses по color key 

= DDBLTFAST SRCCOLORKEY Uses the source surfaces source color key 

= DDBLTFAST WAIT Waits until Bit Fast has finished before returning 


T hese four options аге the total of what is available to you with BitFast. It's not much, but speed comes 
at the price of flexibility. 


M ost of the examples will continue to use Bit rather than 81tFast because of the capabilities it offers. 
Н owever, dont be hesitant to use Bi tFast in а time-critical section of code It can save you. 


THE Nitty-GRittyvys LOCK AND UNLOCK 


So far, | ve presented the high-level ways to access а surface. М ow were going to explore the low-level way: 
using Lock and Unlock. W hen the speed of even the mighty 81tFast just wont do, and you just know you 
can perform the operation faster, you can lock the surface memory and do the work yourself— doing so is 
the ultimate way of working without a net in D irectD raw. 


USING 1DIRECTORAWSURFACE7 LOCK 


Following is the function that locks the surface memory and fetches it for you so that you can do your 
own writing: 


HRESULT IDirectDrawSurface7::Lock( 
LPRECT lpDestRect, 
LPDDSURFACEDESC2 lpDDSurfaceDesc, 
DWORD dwFlags, 

HANDLE hEvent 
js 


T his returns op. ok if successful. Table 6.8 explains the parameters. 


Table 68 IDirectDrawSurface7::Lock Parameters 
Lock Parameter Purpose 


lpDestRect The rectangular area of the surface you want to lock 


lpDDSurfaceDesc А pointer to a DDSURFACEDESC2, which will be filled with the 
information you want 


dwFlags Flags specifying how to lock the surface 
hEvent Not supported. Use NULL. 
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You can lock different parts of the same surface, as long as the rectangles don't overlap. Some of the flags 
аге shown in Table 6.9. 


Table 6.9 Locking Flags 
Flag Meaning 


DDLOCK NOSYSLOCK Tells DirectD raw not to do aW IN 16 lock (which freezes 
the computer, making it impossible to get out other than by 
turning off the computer). Ignored if locking the primary 
surface. 


DDLOCK SURFACEMEMORYPTR Tells DirectDraw that you want a pointer to the surface's 


memor y. 
DDLOCK WAIT Tells DirectD raw to wait for the lock to happen before 
returning. U seful if the surface is otherwise busy. 
DDLOCK_WRITEONLY Specifies that you only intend to write, not read, the surface. 
DDLOCK_READONLY Specifies that you only intend to read, not write, the surface. 


№ ormally, the most useful combination is DDLOCK_SURFACEMEMORYPTR | DDLOCK_NOSYSLOCK | 
DDLOCK WAIT, and to pass NULL aS 1pDestRect, thus locking the entire surface. 


T he 1pDDSurfaceDesc parameter must simply be a clean DDSURFACEDESC2, With all 05, and the dwsize 
parameter set. 


U pon this function's return (assuming that it is successful), the specified area of the surface will be locked. 


So, how do you write to the surface?T he 1psurface and 1Pitch members of DDSURFACEDESC2 help you. 
1pSurface Is the pointer to surface memory. Its original type is void*, so, depending on your bits per 
pixel, you need to cast it to some other type of pointer. О п an 8-bit surface, you'd cast it to an unsigned 
char*. Опа 16-bit surface, you'd use ново», and on a 32-bit surface, омовох. Since you primarily deal 
with 16-bit surfaces, your cast would look like this: 


//cast the surface pointer 
WORD* surfptr-(WORD*)ddsd.lpSurface; 
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T he Pitch member contains a value indicating how many bytes make up a horizontal line оп the surface. 
T his is bytes, not pixels. To get the number of pixels per 
horizontal line you have to divide 1Pitch by the number 


of bytes per pixel. NOTE 
int pixelsperrow=ddsd.1Pitch/(bitsperpix- Logically, on an 800x600x16 surface, 
е1/8); 1Pitch should Бе 1600 (800 pixels wide, 


16 bits per pixel, and 8 bits per byte). 
After you have done this, you can plot to any part of the This is not always so. Different video 
locked area: cards align their memory differently, 


surfptr[x*-y*pixelsperrow]-0;//write a black so 1Pi tch might extend past the 


pixel at x,y 


surface a little.This is just something 
to keep in mind. Don't hardcode your 
N ow that were down to the pixe-plotting level, it's time surface pitches, because even though 
to talk about pixel formats in more detail. T he only real this may work on your machine, 

pixel format I've discussed so far is СОГОВВЕЕ, which you the image will likely look garbled 

use the пов macro to make. Each of the components (red, ВАЗа 
green, and blue) has 8 bits, for a total of 24 bits. to show him. 


But what happens in a 16-bit surface like the ones you've 

been using?T he image in the ball demo loaded up fine because you used GD 1, which did the conversion 
for you. But now you're operating without any nets, using Lock to get the most direct access to your sur- 
face. W hat do you do?Well, you examine the surfaces pixel format by using 
IDirectDrawSurface7::GetPixelFormat. 


HRESULT GetPixelFormat( 
LPDDPIXELFORMAT 1pDDPixelFormat 
ys 


T he 1рорріхе1 Format parameter is simply a pointer to a DOPIXELFORMAT structure. Y ou ve seen this 
structure once before, when you were doing display mode enumeration. 


typedef struct _DDPIXELFORMAT { 
DWORD dwSize; 
DWORD dwFlags; 
DWORD dwFourCC; 
union 
{ 


DWORD dwRGBBitCount; 

DWORD dwYUVBitCount; 

DWORD dwZBufferBitDepth; 
DWORD dwAlphaBitDepth; 
DWORD dwLuminanceBitCount; 
DWORD dwBumpBitCount; 
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} DUMMYUNTONNAMEN(1); 


DWORD dwRBitMask; 

DWORD dwYBitMask; 

DWORD dwStencilBitDepth; 
DWORD dwLuminanceBitMask; 
DWORD dwBumpDuBitMask; 

} DUMMYUNIONNAMEN(2); 

union 
{ 
DWORD dwGBitMask; 
DWORD dwUBitMask; 
DWORD dwZBitMask; 
DWORD dwBumpDvBitMask; 
} DUMMYUNIONNAMEN(3) ; 
union 


{ 


DWORD dwBBitMask; 

DWORD dwVBitMask; 

DWORD dwStencilBitMask; 

DWORD dwBumpLuminanceBitMask; 
} DUMMYUNIONNAMEN(4) ; 

unio 
{ 
DWOR 
DWOR 


dwRGBA1phaBitMask; 
dwYUVAlphaBitMask; 
DWORD dwLuminanceAlphaBitMask; 
DWORD dwRGBZBitMask; 
DWORD dwYUVZBitMask; 

} DUMMYUNIONNAMEN(5); 
} DDPIXELFORMAT, FAR* LPDDPIXELFORMAT; 


D 
D 
D 
D 


| ve bolded the most important fields. W hen you retrieve the pixel format, you first have to clear out the 
DDPIXELFORMAT structure, just as you do with DDSURFACEDESC2 and DDBLTFX. 


//clear out pixel format 

DDPIXELFORMAT ddpf; 

memset (&ddpf,0,sizeof(DDPIXELFORMAT ) ); 
ddpf.dwSize=sizeof(DDPIXELFORMAT ) ; 
//retrieve pixel format of primary surface 
lpddsPrime->GetPixel Format (&ddpf) ; 
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О псе you have the surfaces pixel format, you can use the members of DoPIXELFORMAT to help with your 
writing of pixels. Т he three members, awRBi tMask, dwGBitMask, and dwBBitMask, are binary representa- 
tions of pure red, green, and blue for your surface. DDPIXELFORMAT also shows which bits are valid for each 
of the components. 


For 16-bit surfaces, there are two common pixel formats. T hese formats are called RGB555 and RGB565, 
and they look something like the following: 


RGB555 


Red mask 0111110000000000 
Green mask 0000001111100000 
Blue mask 0000000000011111 
RGB565 


Red mask 1111100000000000 
Green mask 0000011111100000 
Blue mask 0000000000011111 


T he only real difference is the extra green bit in RGB565. O ur eyes are more sensitive to green than to red 
or blue. 


On certain odd video cards, you'll get a BGR instead of an RGB pixel format, meaning that the masks for 
red and blue are switched. T hese video cards are pretty rare, but they do exist. For this reason, you cannot 
make any assumptions about a pixel format, just as you cant make assumptions about a surfaces pitch. 

W hich raises the question, H ow can you plot pixels if you dont know the pixel format? 


Since the pixel format of a surface is never guaranteed to be the same from one machine to the next, writ- 
ing code to write pixels to a surface may seem impossible. Believe me, it's not. T he trick is to use a known 
and stable pixel format that never changes (COLORREF) and to convert the values into the pixel format of 
the surface on which you are working, similar to what GDI does. If you have a limited number of colors 
that you work with a great deal, you can convert them all at once, keep them in a lookup table, and use 
them when you need them. 


In a COLORREF, each of red, green, and blue are values from 0 to 255. 0 indicates that none of the compo- 
nent is present, and 255 indicates that 100% of the component is present. L ogically, then, you could con- 
vert R, С, and B into values from 0.0 to 10 by dividing by 255 and storing them as a float. You can take 
this value and multiply it by the appropriate mask, such as ddpf.dwRBitMask for red, since the mask value 
indicated 10096 of the color component present. Since a fractional component (extra bits that arent in the 
mask) might be set by this multiplication, you can logically AND the mask on to the resulting value. Finally, 
after you do this for all the components and logically or the three values together, you will achieve the 
pixel format conversion from coLorReF to native format. 
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Following are two functions that will allow you to convert back and forth from coLorreF to native 
D irectD raw pixel format. Keep in mind that they are not to be used in a time-critical section— there are 
too many multiplications and divisions to make it really efficient. 


//from dd pixel to colorref 
COLORREF ConvertDDColor(DWORD dwColor, DDPIXELFORMAT* pddpf) 
{ 

//extract color components 

DWORD dwRed=dwColor & pddpf->dwRBitMask; 

DWORD dwGreen=dwColor & pddpf->dwGBitMask; 

DWORD dwBlue=dwColor & pddpf->dwBBitMask; 

//multiply color components by max colorref value (255) 
dwRed*=255; 
dwGreen*=255; 
dwBlue*=255; 
//divide by masks 
dwRed/=pddpf -»dwRBitMask; 
dwGreen/=pddpf ->dwGBitMask; 
dwBlue/=pddpf ->dwBBitMask; 
//return converted color 
return(RGB(dwRed,dwGreen,dwBlue)); 


//from colorref to dd pixel 
DWORD ConvertColorRef(COLORREF crColor, DDPIXELFORMAT* pddpf) 
{ 
//extract color components 
DWORD dwRed-GetRValue(crColor); 
DWORD dwGreen=GetGValue(crColor); 
DWORD dwBlue=GetBValue(crColor); 
//multiply color components by max ddpixel value (the mask) 
dwRed*=pddpf->dwRBitMask; 
Green*=pddpf -»dwGBitMask; 
Blue*=pddpf->dwBBitMask; 
divide by max colorref (255) 
Red/=255; 
Green/=255; 
Blue/=255; 
logical and with mask, to avoid fractions 
Red&=pddpf ->dwRBitMask; 
wGreen&=pddpf ->dwGBitMask; 
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dwBlue&=pddpf->dwBBitMask; 
//merge together, and return the result 
return(dwRed | dwGreen | dwBlue); 


NOTE 


Optimization nuts may be wondering why 1 divided by 255 instead 
of 256. If | were dividing by 256 I could use a bit-shifting operator, 
which would be much faster than doing the division myself. Point 
taken. However, | have tested doing it both ways, and | have found 


that dividing by 256 erroneously converts some of the values. 
Naturally, the errors aren't significant enough to make the image 
look very different, but if you are using a color key other than black, 
there can be problems when you use these functions to help set the 
color key. 


OK, enough about pixel formats! L e's wrap up this part about locking the surface. 
Finally, after you've locked the surface and done whatever you need to do to it, you have to unlock it. 


HRESULT IDirectDrawSurface7::Unlock( 
LPRECT lpRect 
is 


T he 1pRect parameter specifies what area you are unlocking. (It's nuLL if you originally locked the entire 
surface) As when using GetDC/ ReleaseDC on a surface, you should similarly not take too much time 
between calls to Lock and Unlock. | wont show any examples of using Lock/ Unlock on surfaces— this 
will have to be one area you explore on your own.T his type of low-level code tends to get convoluted and 
confusing, and my goal here is not to confuse, but to bring about understanding. 


A DIRECTDRAW WRAPPER 


Speaking of convoluted, have you noticed how much bulkier the D irectD raw examples have been com- 
pared to the examples of earlier chapters? Sheesh! All the posuRFACEDESC?S and DDBLTFXS and so 
on...enough to really work your nerves, right? 


| took the liberty of making a little group of functions to help you with these rather repetitive tasks. T hey 
are contained in DD Funcsh and D D Funcs.cpp. T he following sections contain a brief summary. 
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DOSURFACEDESCL FUNCTIONS 
T his first batch deals with setting up DDSURFACEDESC2 structures. 


= DDSD Clear 
void DDSD_Clear(DDSURFACEDESC2* pddsd); 
T his function clears out the structure and sets the size. Beats the hell out of using memset all the time. 
» DDSD PrimarySurface 
void DDSD PrimarySurface(DDSURFACEDESC2* pddsd); 
T his function sets up a surface description for a primary surface, with no back buffer. It cleans out the sur- 
face description first, of course. 
» DDSD PrimarySurfaceW BackBuffer 
void DDSD PrimarySurfaceWBackBuffer(DDSURFACEDESC2* pddsd, DWORD 
dwBackBufferCount) ; 
T his function sets up a surface description for a primary surface with a back buffer. 
» DDSD OffscreenSurface 
void DDSD OffscreenSurface(DDSURFACEDESC2* pddsd,DWORD dwWidth, DWORD 
dwHeight); 
T his function sets up a surface description for an off-screen surface of a given width and height. 


ое С++ = = FUNCTIONS 
T his next group deals with 005САР52 structures. 


« DDSCAPS Clear 
void DDSCAPS Clear(DDSCAPS2* pddscaps); 
T his function clears out a DDSCAPS2 structure. Yes, you could use memset, and youd have the same number 
of lines. Shhh! 
« DDSCAPS BackBuffer 
void DDSCAPS BackBuffer(DDSCAPS2* pddscaps); 
T his function sets up a DDSCAPS2 structure for a back buffer. 


DD-tTSLTTX FUNCTIONS 
T he pog. FX function group contains functions that manipulate DDBLTFX structures. 
= DDBLTFX Clear 
void DDBLTFX Clear(DDBLTFX* pddbltfx); 


» DDBLTFX ColorFill 
void DDBLTFX ColorFill(DDBLTFX* pddbltfx,DWORD dwColor); 
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PIXEL FORMAT FUNCTIONS 
N ow, pixel formats. 


„ DDPF Clear 
void DDPF Clear(DDPIXELFORMAT* pddpf); 
T his function clears out a DDPIXELFORMAT and sets the dwSize member. 
= ConvertD D Color 
COLORREF ConvertDDColor(DWORD dwColor, DDPIXELFORMAT* pddpf); 
Converts from a native D irectD raw pixd to a COLORREF based on a pixel format. 
= ConvertColorRef 
DWORD ConvertColorRef(COLORREF crColor, DDPIXELFORMAT* pddpf); 
Converts a COLORREF to a D irectD raw native pixa based on a pixel format 


ІРПІКЕСТІЗҒНІЛІ7 FUNCTIONS 
N ext are the functions for creating and releasing 1DirectDraw7 interfaces. 


= LPDD Create 
LPDIRECTDRAW7 LPDD Create(HWND hWnd,DWORD dwCoopLevel); 
Creates an IDirectDraw7 interface and sets a cooperative level. 
= LPDD Release 
void LPDD Release(LPDIRECTDRAW7* 1р1раа); 
Performs a safe rdease of an IDirectDraw7. 


LYPDIRECTORAWSUREFACEZT FUNCTIONS 
T hese are functions to replace the long and messy code required for surface creation. 


» LPDDS CreatePrimary 
LPDIRECTDRAWSURFACE7 LPDDS CreatePrimary(LPDIRECTDRAW7 lpdd,DWORD 
dwBackBufferCount) ; 
Creates an IDi rectDrawSurface7 that will serve as the primary surface, with or without attached 
back buffers. 
= LPDDS GetSecondary 
LPDIRECTDRAWSURFACE7 LPDDS GetSecondary(LPDIRECTDRAWSURFACE7 lpdds); 
Retrieves an attached surface (such as a back buffer). 
= LPDDS CreateO ffscreen 
LPDIRECTDRAWSURFACE7 LPDDS CreateOffscreen(LPDIRECTDRAW7 1pdd,DWORD 
dwWidth,DWORD dwHeight); 
Creates an off-screen surface with an arbitrary width and height. 
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= LPDDS LoadFromFile 
LPDIRECTDRAWSURFACE7 LPDDS_LoadFromFile(LPDIRECTDRAW7 lpdd,LPCTSTR 
lpszFileName); 
Creates a new surface just large enough to load and hold the bitmap file. 
» LPDDS ReloadFromFile 
void LPDDS ReloadFromFile(LPDIRECTDRAWSURFACE7 1рааѕ, LPCTSTR 
lpszFileName) ; 
Use this if you ever need to reload a bitmap onto a surface. 
= LPDDS Release 
void LPDDS Release(LPDIRECTDRAWSURFACE7* 1р1рааѕ); 
Performs a safe release of ап IDi rectDrawSurface7. 
m LPDDS SetSrcColorKey 
void LPDDS SetSrcColorKey(LPDIRECTDRAWSURFACE7 lpdds,DWORD dwColor); 
Sets a single source color key for a surface. 


TASKS Мот INCLUDED 1N THE WRAPPER 


Please note that | do not have any functions in this little wrapper to do B1t, B1tFast, GetDC/ ReleaseDC, 
ОГ Lock/ Unlock. T his is because making such functions would add unneeded overhead. Of course, you 
can still use some of the роветЕХ_* functions to assist in your color fills and other special effects. 


A wrapper should serve two purposes. First, it should make devdopment faster. T his it will do— instead 
of lines and lines of setting up your DDSURFACEDESC2 structures, you can take care of this in a single func- 
tion call. Second, a wrapper should aid in debugging. T his is where my wrapper falls short. If you look 
through the code, there is absolutely no check of the return values from the D irectD raw calls. N aturally, 
when it comes time to make your own wrapper or engine, you will want to include these facilities. 


T hat pretty much covers the basics of 1DirectDrawSurface7, with the exception of one topic. 


EMPOWERING THE USER 


You know that you can press Alt+T ab to switch between the calculator tool, paint program, sound 
recorder, and the bazillion other W indows applications that you may have open (1 tend to have at least six 
open at a time). In a full-screen exclusive mode application, you have total control over video resources. In 
windowed mode, these same video resources have to be shared by all applications. W hen you hit Alt-- Tab 
to switch from a full-screen exclusive mode application to a windowed application, you may lose some or 
all of the video resources you have been using if W indows needs them, whether you like it or not. 


You could respond to the uw svscHAR event (it's the window message that occurs when a system charac- 
ter— anything with an AIt-- ?7?— is pressed) and make sure that you cant switch out of the application. But 
you dont really want to do this, for a number of reasons. First, by doing so you defeat some of the 

W indows features that experienced users are used to. Second, if your application freezes, the user will be 
left with no alternative but to turn the machine off and then back on. 


SURFACES 177 


T he other option is to let W indows seize the video resources when another application is activated and 
then seize them back when the user switches back. T his is the most W indows friendly way to go. То do so, 
you need to respond to the им_АСТТУАТЕАРР window message (see Chapter 1, "Introduction to W IN 32 
Programming,” for a refresher). W hen wParam is nonzero, your application is the one being activated. 

W hen wParam is 0, it is being deactivated. 


W hile deactivated, you don't want to do any rendering, so you should set some sort of “pause” state. 
W hen you are reactivated, you want to make sure that any of the surfaces in video memory are restored 
(since the video resources could have been preempted by W indows). 


In older versions of D irectD raw, you had to check each surface to see if it was “lost” in this way, and then 
restore it if so. In DirectX 7, though, you can do all that with a single call to 
IDirectDraw/::RestoreAllSurfaces: 


HRESULT IDirectDraw7::RestoreAllSurfaces(); 


RestoreAllSurfaces just reallocates the memory for a surface. It does not restore the contents. You have 
to do that yourself by reloading the images from disk. (T he wrapper function LPDDS_ReloadFromFile 15 
quite handy in this regard.) 


IsoH ехб 4.срр is the final example in this chapter. It takes all that you have learned thus far and applies it 
to make your little bouncy-ball demo a solid D irectD raw application. T he main source file is a bit shorter 
than IsoH ехб ЗА .срр, although IsoH ехб_4 is still over 400 lines long. (400 lines isnt very much, and for 
most of it, only one in three lines is an actual piece of code.) Four hundred lines, not counting the lines in 
GD ICanvas.cpp or D D Funcs.cpp, and all you're doing is making a few balls bounce. N o wonder a profes- 
sional game usually has millions of lines of code! 


SUMMARY 


In the end, it isnt the number of lines of code or the size of the executable that counts— it's performance. 
H opefully | ve given you enough to get started. W eve gone over a lot of stuff in this chapter; here are а 
few things to keep in mind. 


An application has one primary surface and may or may not have back buffers. 

O ff-screen surfaces can be used to store bitmaps until they are needed. 

You can use GD! with D irectD raw, but you should limit how often you do so. 

B1t is good for performing color fills and moving blocks from one surface to another. 
Color keys are a way to achieve transparency. 

BltFast is a faster way to move blocks of color from one surface to another. 

To work without a net, you can use Lock/ Unlock. 
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Ve talked quite a bit about D irectD raw surfaces and the capabilities of functions like 87 t. In that dis- 
1 cussion | mentioned briefly the ability to clip the output of вт+ by use of a clipper. In this chapter 
well be covering just that. 111 also cover the (sort оғ) amazing world of D irectD raw in a windowed appli- 
cation. Oh, stop groaning! It'll be fun— | promise. 


USING IDIRECTORAVWCLIPPER 


A clipper in D irectD raw serves the same purpose as a region in GD|— it limits output to a certain area, as 
Figure 7.1 illustrates. 


Figure 7.1 


Clipped versus 
unclipped 


а. 
Unclipped Output Clipped Output 


LI 


T his can be especially important when you're using the entire drawing area of a surface as the clipping 
region and blitting images that do not entirely fit in the display. In D irectD raw, drawing out of bounds 
usually doesnt draw anything unless you are making use of a clipper. 


Н eres something you should always keep in mind: 81+ works with a clipper, but 81tFast doesnt. Using a 
dipper is somewhat slower than not using one. H owever, when youre in a windowed environment (as 
you'll be in the second half of this chapter), a clipper is not only important, it's essential. 


CREATING CLIPPERS 


T here are two ways to create а clipper-— DirectDrawCreateClipper and 
IDirectDraw7::CreateClipper. 
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HRESULT WINAPI DirectDrawCreateClipper( 
DWORD dwFlags, 
LPDIRECTDRAWCLIPPER FAR *IplpDDClipper, 
IUnknown FAR *pUnkOuter 


As with all other D irectD raw functions, this returns pp. ок if successful. 


Of the three parameters for рі rectDrawCreateClipper, only one of them is functional: 1p1pDDC1ipper. 
T he other two, duF1ags and pUnkOuter, are not used, and they must be 0 and NULL, respectively. H ooray 
for unused parameters! 


HRESULT IDirectDraw7::CreateClipper( 
DWORD dwFlags, 
LPDIRECTDRAWCLIPPER FAR *lplpDDClipper, 
IUnknown FAR *pUnkOuter 


T his returns DD_OK on success. 


Н ey, look! It got the exact same parameter list as Di rectDrawCreateClipper, and the same rules 
apply...ignore dwF1ags and pUnkOuter by placing 0 and NULL. 


So, what 15 the difference between these two methods of clipper creation? М ot much, as it turns out. 
DirectDrawCreateClipper Creates а clipper that isnt “owned” by а DirectD raw object, meaning that it 
can be used by any surface, even those created with a different 1DirectDraw7 object. Since you will never 
have more than one IDirectDraw7 object, it seems silly to use DirectDrawCreateCl ipper, SO let's just go 
with using IDirectDraw7::CreateClipper. 


As you have seen, there isnt much to the actual creation of а clipper— just the following code: 


//globals 

LPDIRECTDRAWCLIPPER lIpddclipsNULL; 

//create clipper (lpdd is our IDirectDraw7) 
lpdd-»CreateClipper(O,&l1pddclip,NULL) ; 


SETTING UP A CLIPPING REGION 


W hen you initially create a clipper, it contains nothing— a null dipping region, which is useless. In order 
for a clipper to be useful, you first must fill it with information that describes the clipping region. 
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You do this is by using IDirectDrawClipper::SetClipList 


HRESULT IDirectDrawClipper::SetClipList( 
LPRGNDATA lpClipList, 
DWORD dwFlags 


T his returns pp. ok if successful. 


As with most of the clipper functions, dwF1ags is not used and must be 0. T he important parameter here 
iS 1pClipList, which is a pointer to a RGNDATA Structure A RGNDATA structure is a variable length type 
(which means you usually have to work with it through pointers, malloc, and memcpy). 


typedef struct _RGNDATA { 
RGNDATAHEADER rdh; 
char Buffer[1]; 
} RGNDATA, *PRGNDATA; 


T his contains two members— rdh (a RGNDATAHEADER) and a buffer of chars. T he char buffer is where 
the variable length comes in. Starting at this location is RGNDATA‘ clip list. It can be as long or as short as 
needed to describe the clipping area. 


H ereis the RGNDATAHEADER Structure: 


typedef struct | RGNDATAHEADER { 
DWORD dwSize; 
DWORD iType; 
DWORD nCount; 
DWORD nRgnSize; 
RECT  rcBound; 
} RGNDATAHEADER, *PRGNDATAHEADER; 


T he RGNDATAHEADER describes the dipping region overall— the type of clipping region (i Type), the num- 
ber of rectangles (ncount), and the bounding rectangle for all the rectangles in the clip list (rcBound). Set 
dwSize tO sizeof (RGNDATAHEADER), and set nRgnSize to 0. 


D oes it sound like a real pain to work with these structures? It is. T hat's why youre not going to play with 
RGNDATA and RGNDATAHEADER. Instead, you're going to make your clippers by creating and combining GD I 
regions. 


If you've spent any time working with nGNDATA, you know what kind of problems it has. After months of 
research (О K...only a few hours), | found out that instead of working with the clumsy structure, you can 
create HRGNS and extract the RaNDATA structure once you ve let GD | make the clipping area you want. 
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N ow for a brief review. Table 7.1 lists the functions most commonly used to create regions for GDI. For 
the most part, you'll want to try and stick to CreateRectRgn as much as possible, because it is the least 
slow of the regions as far as clipping is concerned. H owever, you can use any region you create with these 
functions, extract the rectangle list, and use it to set a DirectDrawClipper’s dip list. 


Table 7.1 Region Creation Functions 


Function Type of Region Created 
CreateEllipticRgn An elliptical region 
CreatePolygonRgn A polygonal region 
CreateRectRgn A rectangular region 


CreateRoundRectRgn А rounded rectangular region 


After you use one of these functions to create a clipping region, you have to get it out into a RGNDATA 
structure, since that is what 1DirectDrawClipper::SetClipList takes. То do this, you use the 
GetRegionData function: 


DWORD GetRegionData( 
HRGN hRgn, // handle to region 
DWORD dwCount, // size of region data buffer 
LPRGNDATA lIpRgnData // region data buffer 

у 


Table 7.2 explains the parameter list. 


Table 7.2 GetRegionData Parameters 
GetRegionData Parameter Purpose 


hRgn The region for which you are extracting the RGNDATA 
dwCount The size of the buffer that will receive the information 
lpRgnData A pointer to the buffer 
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T his is one of W indows many functions that retrieve data into a buffer, and it also serves as a function to 
retrieve the size required for the buffer by passing NULL as 1pRgnData. So, your extraction is actually per- 
formed in a number of steps: 


//retrieve buffer size 

DWORD dwBufSize-GetRegionData(hrgn,O,NULL) ; 
//allocate large enough buffer 

LPRGNDATA lprd-CLPRGNDATA)malloc(dwBufSize); 
//extract region data 
GetRegionData(hrgn,dwBufSize,lprd); 

//assign clip list to ddclip 
Ipddclip->SetClipList(lprd,0); 


ASSIGNING A CLIPPER TO A SURFACE 


Just as an HRGN by itself isnt very useful, an 1DirectDrawClipper is of по usein a void. It has to be 
assigned to an IDirectDrawSurface7 by using IDirectDrawSurface7::SetClipper 


HRESULT SetClipper( 
LPDIRECTDRAWCLIPPER 1pDDClipper 
); 


T his returns pb. ok if successful. 


At last! A function involving clippers that doesnt have a useless parameter in it. 1p0DC1ipper is a pointer 
to the dipper that you are assigning to the surface. You can assign a dipper to more than one surface at the 
same time (usually, you'll only assign a clipper to the back buffer, but there are exceptions). 


To remove a clipper from a surface, you can pass NULL in the call to 
IDirectDrawSurface7::SetClipper. 


Let's do a quick example. Load up IsoH ех7 L.cpp.T his is based оп IsoH ex6. 4.cpp. Two functions 
involving clippers have been added to D D Funcsh and DD Funcs.cpp. Figure 7.2 shows the output. 
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Figure 7.2 
IsoH ex7_1.cpp output 


By far the most common use of a clipper is to encompass the entire screen. H owever, in many games, this 
isnt always the best plan. You may have а playing area, a status bar on one side, a message bar on the top 
or bottom, etc., etc. In cases like these, writing only to the appropriate area takes some careful planning on 
your part. Clippers can help— you can make one clipper for the view area, one for the status bar, one 

for the message bar, and so on, and use IDirectDrawSurface7::SetClipper to switch between them 

as needed. 


T hat's about all | have to say for now about clippers. T hey are a powerful tool when used correctly, but 
they are not always the best solution. [п a game where speed really counts, you will want to use your own 
sort of clipping. We will visit clippers again briefly in a moment. 


WINDOWED DIRECTORAW 


You may be wondering why I'm covering windowed D irectD raw at all. DirectD raw games are all full- 
screen, right? Well, true... mostly. Н owever, it is always а good thing to give your user the ability to choose 
whether to run full-screen or in a window. Empowering the user to do so is important, just like when giv- 
ing the user the ability to switch display modes based on personal preferences. 


DIFFERENCES BETWEEN FULL-SCREEN AND 
WINDOWED DIRECTORA 


T here arent actually that many differences between a full-screen D irectD raw application and a windowed 
one. H owever, the changes that do exist are important. T hey are summarized in Table 7.3. 
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Table 7.3 Full-Screen versus W indowed DirectDraw 


Item Full-Screen Windowed 
Flags sent to IDirectDraw7:: DDSCL FULLSCREEN | DDSCL. NORMAL 
SetCooperativeLevel DDSCL EXCLUSIVE | 

DDSCL_ALLOWREBOOT 
Call IDirectDraw7::SetDisplayMode Yes No 
Create back buffers Yes No 
Use a clipper O ptional Strongly suggested 


Глеғінү MODES 


Since you cant call SetDisplayMode, you are stuck with whatever the user has currently set up. If the user 
is in an 8-bit mode, so are you. Being stuck in 8-bit mode will probably mean that your game will not 
look as good as it can, and it also means that if you want to support this mode, you'll have to make use of 
an IDirectDrawPalette. 


First, you cant allow the program to run in ап 8-bit mode. You can determine how many bits per pixel the 
display has by calling IDirectDraw7::GetDisplayMode: 


HRESULT GetDisplayMode( 
LPDDSURFACEDESC2 lpDDSurfaceDesc?2 
); 


T his returns 00 ok if successful. 1pDDsurfaceDesc? points to a DDSURFACEDESC2. Examine the pixel for- 
mat to retrieve the bits per pixel. T his way is not very empowering to your users, and it might completely 
alienate them. And if they dont play your game, they dont tell their friends to buy it, and you make less 
money (and you have to settle for a М eon instead of a Ferrari). 
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Second, you can detect the bits per pixel. If the current display mode set by the user shows that it's in an 
8-bit mode or less, pop up a message box warning him that the display might not look correct in that 
mode and asking if he would like to continue (see Figure 7.3). 


Continue Figure 7.3 


This game was designed to run in high-color mode. Continuing under your current display settings may A friendly way to warn 
not look as good. Would you like to continue? y ; 
about 8-bit graphic 


Е No | performance 


N ow the user has been warned, and һе is less likely to e-mail you telling you that your game sucks. Little 
touches like this will make your games sean more professional. 


No BACK BUFFERS 


Another problem with windowed D irectD raw is that you cant make use of a back buffer, which means 
you cant use F1ip. You can solve this problem by making an off-screen surface that is the exact size (or the 
maximum size) of the client area, and once per frame, blitting from this surface to the primary. In some 
cases, it wont be as smooth as when using a back buffer, but that's the price of being in a window. 


W hich brings me to the problem of the primary surfaces coordinates. N o matter whether you are full- 
screen or windowed, the primary surface takes up the entire area of the visible surface T his is significant. It 
means that (0,0) on the primary surface is (0,0) on the screen, and not (0,0) in your window's client 
area— unless your client area has (0,0) at screen (0,0). Luckily, W indows gives you the ability to convert 
between client coordinates and screen coordinates, with the ст ientToScreen function: 


BOOL ClientToScreen( 
HWND hWnd, // handle to window 
LPPOINT lpPoint // screen coordinates 
); 


T his returns nonzero on success or 0 on failure. Table 7.4 explains the parameter list. 
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Table 7.4 ClientToScreen Parameters 
ClientToScreen Parameter Purpose 


hWnd W indow from which you are converting client coordinates 


1рРо1пї On entry, the client coordinate; on exit, the screen 
coordinate (pointer) 


W hen you want to blit to only the window, you just convert from the (0,0) client coordinate to whatever 
the screen coordinate is, like so: 


//(0,0) client coordinate 

POINT pt; 

pt.x-0; 

pt.y-0; 

//convert to screen coordinate 
ClientToScreen(hWndMain,&pt); 

//pt now contains the screen coordinates 


Simple, no? 


You could convert the client to screen coordinates every frame, but you don't necessarily have to. Y ou can 
just respond to the им. Move window message, and keep the screen coordinates for the (0,0) client coordi- 
nate in a global somewhere. 


CLIPPERS IN WINDOWED DIRECTDRAW 


In full-screen D irectD raw, clippers are optional and often arent used. In windowed D irectD raw they are 
almost mandatory, because the viewable area of the primary screen through your window may change 
based on other windows in the system and the placement of your window. Fortunately, you dont have to 
do the clipping by yourself; you can have D irectD raw automatically do it by calling 
IDirectDrawClipper:SetHWnd: 


HRESULT IDirectDrawClipper::SetHWnd( 
DWORD dwFlags, 
HWND hWnd 
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T his returns po ox if successful. Т he awF1ags parameter must be 0.T he hind parameter is a window 
handle from which the clipper obtains the clip list. О nce you call this function and then call the primary 
surfaces SetC1ipper function, that’s it— D irectD raw takes care of the rest. 


IsoH ех7 2.срр puts all this stuff about windowed DirectD raw into practice Figure 7.4 shows the output. 


Figure 7.4 


Balls bouncing in a window 


T he first thing you'll notice when running this program is that the balls seem to bounce around much 
more quickly. H owever, you should also notice that the smoothness is gone and the balls leave an 
afterimage. 


T he main differences between the full-screen bouncing ball demo and the windowed one are as follows: 


= The IDirectDraw7 object has a cooperative mode of DDSCL. NORMAL. 

= M odes are not enumerated. 

= T he primary surface has no back buffers. 

= T he “back buffer” that is created is in actuality an off-screen surface. 

= A variable called ptPrimeB1t keeps track of the (0,0) dient position in screen coordinates. It is first calcu- 
lated in Prog Init and is recalculated in response to WM MOVE. 

= Instead of two previous positions for the ball, you keep track of only one (since the contents of the “back 
buffer" and the primary do not get exchanged). 

= Because your “back buffer" is not a true back buffer, you have to release it the same as any other surface. 

= T he demo checks to see that the bpp of the display mode is at least 16 and displays a warning message if 
it is not. 
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SUMMARY 


T his finishes up all you really need to know about DirectD raw to get started. As you become more famil- 
iar with DirectD raw you'll naturally want to explore more. | regret that | cannot cover it in more detail, 
but | need to get on to the really fun stuff. 


Н eres what you have learned: 


= You can dip output with IDirectDrawClipper. 
= Empowering the user is important. 
= W indowed D irectD raw is a pain in the rear. 
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J ust as you used D irectD raw to seize control of your display, you will use D irectSound to grab the 
resources of your sound card. DirectSound and D irectD raw have a lot in common as far as how 
things are set up, but we'll get to that in a moment. 


First, a little history. Back in the Stone Age of about 5 years ago, using digital sound on the PC was a 

Н erculean task. T here were hundreds of sound card manufacturers, and each one had its quirks. If you 
wanted to write a game that used them, you had to choose which you were going to support and stay with 
it. It was indeed a dark day for the rebellion. After W indows 95 came out, there was only limited support 
for playing sounds, and there were problems with latency (the time between when you told a sound to play 
and when it actually started playing), so using digital sound in W indows 95 was something of a joke. 


T hat was before D irectX came out. W ith D irectSound, you no longer have to worry about who the manu- 
facturer of your sound card is. M ost sound cards now have drivers that make them compatible with 
DirectSound, emulating features if needed. It's a beautiful thing. 


Even though this book really isnt about sound programming, | felt a certain obligation to at least do the 
basics of D irectSound. N owadays, any game written is required to have sound, and usually music as well. 


THE NATURE OF SOUND 


You may or may not have ever given thought to the nature or physics of sound. It's really a fascinating sub- 
ject. W dl, not as fascinating as game programming, of course, but it's still pretty darn neat! 


How Our EARS WORK (THE REALLY 
SIMPLIFIED VERSION) 


O ur ears are truly magnificent instruments. T hey allow us to interpret subtle changes in air pressure to gain 
dues about our environment. Аз | type this, | am listening to the blowing sound of my computer's power 
source fan and the clicks of my fingers on the keys. (І tend to work quite late at night, and | prefer quiet, 
unlike many of my colleagues, who listen to music while working.) 


W hen | press a key on my keyboard, | displace air, which sends a shock wave through the atmosphere 
between my keyboard and my ears. T hese shock waves vibrate my eardrums, which moves tiny bones in my 
inner ear, which causes compression of some fluid in my cochlea, which sends electrical signals to my 
brain, which then realizes that it's hearing my keystrokes. It is a wondrous thing. T he process is illustrated 
in Figure 8.1. 
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Figure 8.1 


Something disrupts the air Rough sketch of how 
ears work 


The air disruption travels in waves to the ear 


The eardrum vibrates 


The inner ear bones are moved by the eardrum 


The fluid within the cochlea is compressed and decompressed 


The fluid pressure changes are changed into an electric 
Signal that is sent to the brain 


How SPEAKERS WORK 


If our ears do nothing more than detect variations in air pressure, speakers must do nothing more than 
create variations in air pressure. In fact, a speaker is very much like the opposite of an ear (see Figure 8.2). 


Figure 8.2 
A wire carries an electrical current to the speaker How speakers work 


| 
A magnetic field shifts a magnet within the speaker 


The magnet's movement causes a diaphram to move 


The diaphram disrupts the air, causing a sound to be emitted 


DIRECTSOUND ЕЕ 


А speaker makes noise by moving а cardboard or paper membrane (Kind of like an eardrum) back and 
forth, thus distorting air pressure. It does this by moving alittle magnet back and forth (similar to but 
opposite in function from the tiny bones in the inner ear). T his magnet is moved around by applying dif- 
ferent magnetic fields, which are themselves created by electrical charges in wires. 


How SOUND CARDS WORK 


In the speaker-to-ear comparison, a sound card performs approximately the same function as the cochlea. 
M uch likethe cochlea takes the vibration and converts it into a meaningful signal for the brain, the sound 
card takes a meaningful signal and translates it into an analog electrical current that is then applied to the 
speaker's magnet. T his process is illustrated in Figure 8.3. 


Figure 8.3 
Sound card accepts a digital signal How sound cards work 


Sound card's circuirty converts the digital 
signal into an analog electrical current 


Electrical current is sent out to the speaker 


On the flip side, the sound card сап also convert the other way, through the microphone, where, instead of 
taking a digital signal and converting it into an analog current, it takes analog current and converts it into 
a digital signal. 


THE WINS2@ Way то PLAY SOUNDS 


Before we get into what DirectSound has to offer, let's take a moment to explore what W IN 32 has to offer 
(it aint much). By doing so, you may appreciate DirectSound more. 


To make use of W IN 325 sound capabilities, you must include mmsystem.h in your program, and you 
must link to the winmm.lib library. T he sum total of theW IN 32 support for playing digital sound files 
(WAV files) rests in the hands of a single function, P1aySound: 
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BOOL PlaySound( 
LPCSTR pszSound, 
HMODULE hmod, 
DWORD fdwSound 


js 


T his returns nonzero on success. T able 8.1 explains the parameters. 


Table 8.1 PlaySound Parameters 
PlaySound Parameter Purpose 


pszSound File name for the W AV file 

hmod Handle to the module containing the sound resource. Use 
NULL, because you are loading from a file. 

fdwSound Flags concerning how the sound is to be played or where it 
is from 


A typical call to P1aySound looks like this: 


//play the bounce sound 
PlaySound("bounce.wav",NULL,SND_FILENAME | SND_ASYNC); 


= SND FILENAME and SND_ASYNC are a couple of the flags that can be passed. Н ere are some others, as well 
as their meanings: 

= SND_ASYNC T he sound will be played asynchronously (that is, the function returns immediately without 

waiting for the sound to be played) 

и SND FILENAME pszSound is a file name 

= SND_LOOP T he sound played loops over and over 

= SND NOWAIT If the sound driver is busy, returns FALSE and doesnt play the sound 

= SND PURGE Stops any sounds that are playing for the calling process 

и SND SYNC Waits until the sound is finished playing before returning 


M ost of the time, you will want SND_ASYNC and SND. FILENAME, as shown in the preceding code 
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Load up 150Н ex8 1.срр.Т his is the same old bouncing ball demo that weve been working on for the last 
few chapters, only this time a sound will play each time a ball strikes the edge of the screen. 


//bounds checking 


//left side 
if(ptBallPosition[index].x«-0) 
{ 
//change direction 
ptBallVelocityLindex].x=abs(ptBallVelocityLindex].x); 
//play sound 
PlaySound("bounce.wav",NULL,SND_FILENAME | SND_ASYNC); 
} 
//top side 
if (ptBallPosition[Lindex].y<=0) 
{ 
//change direction 
ptBallVelocityLindex].y=abs(ptBallVelocityLindex].y); 
//play sound 
PlaySound("bounce.wav",NULL,SND_FILENAME | SND_ASYNC); 
} 
//right side 
if(ptBallPosition[index].»x»-(int)dwDisplayWidth-gdicBall.GetWidth()) 
{ 


//change direction 
ptBallVelocityLindex].x=-abs(ptBallVelocityLindex].x); 
//play sound 
PlaySound("bounce.wav",NULL,SND_FILENAME | SND_ASYNC); 
} 
//bottom side 
if(ptBallPositionLindex].y>=(int)dwDisplayHeight-gdicBall.GetHeight()) 
{ 


//change direction 
ptBallVelocityLindex].y=-abs(ptBallVelocityLindex].y); 
//play sound 

PlaySound("bounce.wav",NULL,SND_FILENAME | SND_ASYNC); 


If you run this, you'll see the full-screen bouncing ball demo and hear bouncing sounds. D espite the sim- 
plicity of the demo, you might actually begin to believe that, instead of little pictures of circles being 
erased and redrawn and digital sounds playing, there are little balls bouncing around inside your computer. 
T hat's what adding sound capabilities is all about... added realism. 
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PlaySound Is fine if you dont need accurate timing. A larger sound takes longer to load, so the lag would 
be more noticeable than the lag with bounce.wav, which is such a small sound (3K) that you dont notice 
the latency (unless, of course, you are an android with superhuman hearing). 


THE IDIRECTSOUND OBJECT 


Just as DirectD raw has IDirectDraw7, DirectSound has 1DirectSound, and for the exact same reason. 
[DirectSound abstracts the capabilities of sound hardware, in the same way that IDirectDraw7 abstracts 
display hardware. (T here is по 1DirectSound7, because there really hasn't been all that much revision in 
the way sound cards work; you just use the plain old 10irectSound interface) 


CREATING THE DIRECTSOUND OBJECT 
To create an IDirectSound Object, use DirectSoundCreate. 


HRESULT WINAPI DirectSoundCreate( 
LPCGUID lpcGuid, 
LPDIRECTSOUND * ppDS, 
LPUNKNOWN — pUnkOuter 

js 


T his returns 05 ox if successful (it returns pp. ок for DirectD raw or 05 ox for DirectSound). Table 8.2 
explains the parameters. 


Table 8.2 DirectSoundC reate Parameters 
DirectSoundCreate Parameter Purpose 


lpcGuid The GUID of the sound drivers to use. (W e will 
Use NULL.) 
ppDS A pointer to an LPDIRECTSOUND variable that will be 


filled with a pointer to a new DirectSound object. 
pUnkOuter COM aggregation stuff. Use NULL. 
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T his should look a little familiar, because it's a lot like the call to Di rectDrawCreateEx. 
T he code required to create an 1DirectSound object looks like the following: 


//variable declaration(global) 
LPDIRECTSOUND lpdssNULL; 
//creating IDirectSound object (usually in Prog Init) 
DirectSoundCreate(NULL,&Ipds, NULL) ; 

//cleaning up IDirectSound(Prog Done) 

if(lpds) 

{ 


lpds->Release(); 
lpds-NULL; 
} 


See? It's so much like D irectD raw, it's scary. 


SETTING THE COOPERATIVE LEVEL 
Another similarity between D irectD raw and DirectSound is the use of a cooperative level. 


HRESULT IDirectSound: :SetCooperativeLevel ( 
HWND hwnd, 
DWORD dwLevel 


E 


T his returns 05 ox if successful. Table 8.3 explains the parameter list. 


Table 8.3 IDirectSound::SetC ooperativeLevel 
Parameters 


SetC ooperativeLevel Parameter Purpose 


hwnd The main window of the application that is using 
DirectSound 


dwLevel The cooperative level flags (discussed next) 
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T he flags for D irectSound's cooperative levels are as follows: 


= DSSCL_NORMAL T he application plays well with others, but output is restricted 

= DSSCL PRIORITY T heapplication can change the format of the output 

и DSSCL EXCLUSIVE DDSCL_PRIORITY, plus no other applications can play sounds 

= DSSCL WRITEPRIMARY Total control over the sound hardware, probably more than you want 


For your purposes, DSSCL_NORMAL Will suffice. 


//set normal cooperative level 
lpds-»SetCooperativeLevel(hWndMain,DSSCL NORMAL); 


W hen in DSSCL_NORMAL, you are stuck with a 22K H 2 8-bit stereo format. T his isnt exactly the best sound 
format in the world, but it will suffice for your purposes. Exploring the other sound formats is an exercise 
| leave to you. 


T hat's all you need to do to set up your 1Directsound object. If you were using a cooperative level other 
than DDSCL_NORMAL, there would be extra steps. 


THE IDirREcThHOUNDEÉUFFER OBJECT 


N ow that you've established contact with your sound card, you need to give it something to do. A sound 
card does one thing and does it well: it plays sounds. Y ou keep these sounds (or, at least, binary representa- 
tions of them) in buffers. 


CREATING SOUND BUFFERS 
Create sound buffers by USING IDirectSound: :CreateSoundBuffer: 


HRESULT IDirectSound: :CreateSoundBuf fer ( 
LPCDSBUFFERDESC lpcDSBufferDesc, 
LPLPDIRECTSOUNDBUFFER lplpDirectSoundBuffer, 
IUnknown FAR * pUnkOuter 

Ё 
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T his returns 05 ox if successful. Table 8.4 explains the parameters. 


Table 8.4 IDirectSound::C reateSoundBuffer 
Parameters 


CreateSoundBuffer Parameter Purpose 


lpcDSBufferDesc Pointer to a DSBUFFERDESC (similar in purpose to a 
DDSURFACEDESC) that describes the buffer 


lplpDirectSoundBuffer Pointer to an LPDIRECTSOUNDBUFFER pointer that 
will be filled with a pointer to an 
IDirectSoundBuffer interface. 


pUnkOuter COM aggregate stuff. Use NULL. 


T he pSBUFFERDESC structure tells how a buffer is to be created. 
typedef struct { 


DWORD dwSize; 

DWORD dwFlags; 

DWORD dwBufferBytes; 

DWORD dwReserved; 

LPWAVEFORMATEX lpwfxFormat; 

GUID guid3DAlgorithm; 
) DSBUFFERDESC, *LPDSBUFFERDESC; 


Table 8.5 shows the meaning of the various DSBUFFERDESC members. 


Table 8.5 DSBUFFERDESC Members 


DSBUFFERDESC Member Meaning 

dwSize Size of this structure 

dwFlags Flags for how to create the buffer 
dwBufferBytes N umber of bytes to allocate for the buffer 
dwReserved Reser ved 

lpwfxFormat Pointer to a WAVEFORMATEX structure 
guid3DAlgorithm For 3D sound, which | will not cover 
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You must set the dwSize parameter to sizeof(DSBUFFERDESC). 
Here are some possible flags for dwFlags: 


= DSBCAPS CTRLFREQUENCY Controls the frequency of the sound 

= DSBCAPS CTRLPAN Controls the panning (left-right position) of the sound 

= DSBCAPS CTRLVOLUME Controls the volume for this sound 

= DSBCAPS LOCHARDWARE T he sound is stored in the sound сага’ hardware memory, and you can make use 
of hardware mixing (not necessarily available). 

= DSBCAPS LOCSOFTWARE T he sound is stored in software (system memory). 

= DSBCAPS STATIC T he buffer is intended to be loaded once and played many times, rather than used for 
streaming. 


H ere are a few words of advice concerning these flags: 


= Dont use more than are necessary. If you want to control the volume, that's fine but if you dont need some 
thing like frequency control, dont ask for it. 

и |f you attempt to use the DSBCAPS LOCHARDWARE flag, be sure to have a fallback plan (for example, respond 
to a return code that is not 05 OK). 

= Most of your sounds are likely to be static, so make good use of the DSBCAPS_STATIC flag. 


I'll go into more detail on some of these flags later. 


THE WAVEFORNMNATEX STRUCTURE 


Sounds come in many different formats— mono (single-channel), stereo (dual-channel), 8-bit, 16-bit, 
11KHz, 22KH z, and 44KH 2. As you can see, a sound file can have a number of properties, and these are 
specified in a WAVEFORMATEX Structure: 


typedef struct { 

ORD wFormatTag; 

ORD nChannels; 

DWORD nSamplesPerSec; 
DWORD nAvgBytesPerSec; 
ORD nBlockAlign; 

ORD wBitsPerSample; 
ORD cbSize; 

} WAVEFORMATEX; 
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Table 8.6 explains the members of WAVEFORMATEX. 


Table 8.6 WAVEFORMATEX Members 
WAVEFORMATEX Member Meaning 


wFormatTag The waveform audio type (typically 
WAVE FORMAT PCM, which is used by WAV files) 

nChannels Either mono (1) or stereo (2) 

nSamplesPerSec The frequency of the sound, typically 11025, 22050, 
or 44100 

nAvgBytesPerSec The number of bytes per second 

nBlockAlign The number of bytes in a block (depends on 
wBitsPerSample and nChannels) 

wBitsPerSample 8 or 16, specifying the size of a sample in bits 

cbSize Extra data; ignored when using WAVE FORMAT PCM 


15 your head swimming with all of these audio terms? D ont worry about them too much. You dont actu- 
ally care all that much about how sounds work; you just want to load them and play them. 


T he members of wAVEFORMATEX that you need to supply numbers for are wFormatTag, nChannels, 


nSamplesPerSec, and wBitsPerSample. You should always make cbSize equal to 0. T he rest can be cal- 
culated: 


nBlockAlign = nChannels * wBitsPerSample / 8; 
nAvgBytesPerSec = nBlockAlign * nSamplesPerSec; 


So, to create a sound buffer, do this: 


//declare buffer (global) 
LPDIRECTSOUNDBUFFER 1раѕр; 

//set up a buffer description 
DSBUFFERDESC dsbd; 

//code to fill out dsbd 

//create buffer (initialization) 
lpds-»CreateBuffer(&dsbd,&lpdsb,NULL) 
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//safe release (cleanup) 
if(lpdsb) 
{ 


lpdsb->Release(); 
lpdsb-NULL; 


CONTROL FLAGS 


T here are a number of control flags that can be sent to DirectSound to specify how much and what sort 
of control you want for individual sounds. All of these control flags start with DSBCAPS_.T here are 
more control flags than are described here; I'll just mention the commonly used ones. 


FREQUENCY 


T he frequency of a sound corresponds to the nSamplesPerSec member of DSBUFFERDESC and is typically 
11025, 22050, or 44100. T he higher the frequency, the more bytes per second (hence, a larger WAV file), 
and the better the sound quality. 


You set the frequency of the sound when you create the buffer, but if you include a DSBCAPS_CTRLFRE- 
QUENCY flag in your buffer description, you can change it later with IDirectSoundBuffer: :SetFrequency: 


HRESULT IDirectSoundBuffer::SetFrequency( 
DWORD dwFrequency 
); 


T his returns ps ok on success. dwFrequency Is the new frequency at which you want the sound to be 
played. Т his number can be іп the range of DSBFREQUENCY_MIN to DSBFREQUENCY. MAX. Another constant, 
DSBFREQUENCY. ORIGINAL, reverts the sound to its original frequency. 


W hen you change the frequency of a sound, both the length and the pitch change. If you put in a smaller 
number, the sound will be longer, and it will be lower in tone If you put in a larger number, the sound 
will play more quickly, and it will sound higher (the chipmunk effect). 


To retrieve the frequency of a sound, use IDirectSoundBuffer:GetFrequency: 


HRESULT IDirectSoundBuffer::GetFrequency( 
LPDWORD lpdwFrequency 
); 
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T his returns os ox if successful. Т he 1pdwFrequency parameter is a pointer to a оиоко that is filled with 
the sound's frequency. 


VOLUME 


If you use the DSBCAPS_CTRLVOLUME flag, you can make use of volume control for a sound. You might be 
surprised at how the volume controls in DirectSound work, because volume control is actually attenuation 
control. In other words, you dont actually set how loud a sound is; you set how muted it is. T he second 
thing that might give you trouble is that attenuation is a logarithmic scale, specified in hundredths of a 
decibel (dB). Crazy, huh? 


So, what the heck is a decibel? A decibel is one-tenth of a bel. (N ot too helpful, | know.) A sound that is 
2 bes (20 decibels) is 10 times louder than a sound that is 1 bel (10 decibels). To flip this around, a 
sound that is attenuated by 10 decibels is 10 times softer than a sound that is not attenuated at all. To 
specify attenuation, you use a minus sign. Because the units are in hundredths of a decibel, attenuating by 
10 dB has а value of - 10000. T he maximum attenuation value for DirectSound is 05В/011/МЕ МІМ, which 
equals - 100000, or - 100 dB, which is 10 billion times softer than a nonattenuated sound— for all intents 
and purposes, silence. О n the other end of the scale is DSBVOLUME_MAX, which is 0, meaning no attenua 
tion. 


Set the attenuation with a call to 1DirectSoundBuffer:SetVolume: 


HRESULT IDirectSoundBuffer::SetVolume( 
LONG lVolume 
ys 


T his returns 05 ok on success. T he 1vo1ume parameter specifies the attenuation value for this sound. 
To retrieve the attenuation value, use IDirectSoundBuffer: :GetVolume: 


HRESULT IDirectSoundBuffer::GetVolume( 
LPLONG lplVolume 
$ 


Т his returns ps ok on success. Т he 1p1Volume parameter is a pointer to а Lone that is filled with the 
attenuation value. 


M ost of the time, you wont want to work with a logarithmic scale for setting volumes, and your users def- 
initely won't. U sually, you'll want some nice scalar measure for volumes, like a percentage; one way to do it 
is to calculate the logarithmic values for the percentages from 0 to 100 and store then in a lookup table or 
just calculate them on-the-fly. To do this, just use the following equation. 
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CAUTION 

Be careful not to put a 0 into the 1 og function, or you will cause an infi- 
nite feedback loop that will destroy all matter in the universe! Or you'll 
get a runtime error, which is much, much worse. 


//the 10910 function requires the use of math.h 
attenuation-loglO0(volume)*1000; //volume is a value between 0 and 1 


PANNING 


Pan is similar in function to volume and works in a similar way. Pan sets the relative volume between the 
two speakers. T he DSBCAP_CTRLPAN flag is required to change the pan. 


Panning is accomplished by attenuating either the left or right speaker's output, similar to how volume 
attenuates both. T his attenuation is in addition to the attenuation because of volume control. T he units 
are the same— hundredths of a decibel. Positive values attenuate the left speaker, leaving the right speaker 
alone, and negative values attenuate the right speaker, leaving the left speaker alone. A value of 0 means no 
attenuation to either speaker. 


То set the pan, use IDirectSoundBuffer: :SetPan: 
HRESULT IDirectSoundBuffer::SetPan( 


LONG ТРап 
72 


T his returns ps ok if successful. 1Pan species how to pan the sound. (М oticing a pattern with these func- 
tions?) 

T here are а few constants that you can use with SetPan. 05ВРАМ LEFT (equal to - 10000) silences the 
right speaker, DSBPAN_RIGHT (equal to 10000) silences the left speaker, and DSBPAN_CENTER sets no atten- 
uation for either speaker. 


To retrieve the current panning for a sound, use IDirectSoundBuffer: :GetPan: 


HRESULT IDirectSoundBuffer::GetPan( 
LPLONG 1р1Рап 
); 
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T his returns os ox if successful. Т he 1p1Pan parameter is a pointer to а гоме that is filled with the cur- 
rent pan level. 


LOCKING AND UNLOCKING SOUND BUFFERS 


Before we actually get into locking and unlocking a sound buffer, we must first discuss the concept of a 
sound buffer. А DirectSound sound buffer is conceptually circular, allowing you to loop a buffer indefi- 
nitely, or even to have streaming content to a buffer (that is, writing to one section of the buffer while 
another section is playing). Because of this, when you lock a buffer, instead of just getting a single pointer 
to the memory contained in the buffer, you might get two pointers (because you might be playing the 
middle of the buffer while you are locking two of the ends). | won't cover streaming buffers, but | thought 
that you should be aware of them. 


To lock the buffer, you use the 1Di rect SoundBuffer: : Lock function: 


HRESULT IDirectSoundBuffer::Lock( 
DWORD dwWriteCursor, 

DWORD dwWriteBytes, 

LPVOID IplpvAudioPtr1, 

LPDWORD lpdwAudioBytesl, 

LPVOID IplpvAudioPtr2, 

LPDWORD lpdwAudioBytes2, 

DWORD dwFlags 


me 


T his returns ps ok if successful. Table 8.7 explains the parameters. 
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Table 8.7 IDirectSoundBuffer ::Lock Parameters 
Lock Parameter Purpose 


dwWriteCursor O ffset from the start of the buffer (in bytes) where you want the 
lock to start 

dwWriteBytes Size, in bytes, of the portion you want to lock 

lplpvAudioPtr1 Pointer to a pointer that will be filled with the memory location of 


the start of the locked portion 


lpdwAudioBytes1 Number of bytes pointed to by what will be filled into 
lplpvAudioPtri 


lplpvAudioPtr2 If the buffer had to wrap around (go from the end to the beginning 
again), this is filled with the second pointer, so you can continue to 
write. If NULL, 1plpvAudioPtr1 points to the entire locked area of 
the buffer. 


lpdwAudioBytes2 The size in bytes of the area that starts at 1p] pvAudioPtr2 
dwFlags Flags specifying how you want to lock the buffer 


Since you will be working with static buffers only, you can ignore 1p1pvAudioPtr? and pass NULL. 

Н owever, you still need to pass in a pointer to a DWORD for 1pdwAudioBytes?, even though it will be filled 
with 0. Also, since you are dealing with static buffers, you pass DSBLOCK_ENTIREBUFFER, which means that 
dwWriteBytes iS ignored and you can pass 0 there as well. 


To lock a buffer, do the following: 


//pointer to buffer (it is UCHAR* to work with 8 bit audio, if using 16 bit, you 
should use USHORT*) 

UCHAR* pBuffer; 

//buffer sizes 

DWORD dwBufl; 

DWORD dwBuf2; 

//lock the buffer 
lpdsb-»Lock(0,0,(void**)&pBuffer,&dwBufl,NULL,&dwBuf2,DSBLOCK ENTIREBUFFER); 
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After locking the buffer, you can fill it with whatever data you want (usually by using memcpy). W hen you 
are all done use IDirectSoundBuffer: :Unlock: 


HRESULT IDirectSoundBuffer: :Unlock( 
LPVOID lpvAudioPtrl, 
DWORD dwAudioBytesl, 
LPVOID IpvAudioPtr2, 
DWORD dwAudioBytes2 


T his returns 05 ok on success. Т he parameters for Unlock should look familiar, because they are most of 
the parameters for Lock. 


Do the following to unlock the buffer: 
lpdsb-»Unlock(pBuffer,dwBufl,NULL,0O); 
N ow you're ready to start using the sound. 


PLAYING SOUNDS 


O nce you have your sound buffer created and filled with the proper data, it's time to put it to work by 
playing it. To do so, use IDirectSoundBuffer: :Play: 


HRESULT IDirectSoundBuffer::Play( 
DWORD dwReservedl, 
DWORD dwPriority, 
DWORD dwFlags 


T his returns os ok if successful. Table 8.8 explains the parameters. 


Table 8.8 lIDirectSoundBuffer ::Play Parameters 


Play Parameter Purpose 


dwReservedl No purpose. Pass a 0. 
dwPriority Meaningless when using the DSSCL_NORMAL cooperative level. Pass a 0. 
dwFlags Pass 0 to play the sound once. Pass 05ВРІ АҮ LOOPING to loop the 


sound repeatedly. 


208) ISOMETRIC GAME PROGRAMMING WITH, DIRECTX 7,0 


//play a sound once 
lpdsb->Play(0,0,0); 

//play a sound continuously 
lpdsb-»Play(0,0,DSBPLAY LOOPING); 
//stop a sound 

lpdsb-»5StopO; 


DUPLICATING SOUND BUFFERS 


T he problem with DirectSound buffers is that, at any given time, only one copy can be playing. To play 
more than one copy of the same sound, you can do one of two things: you can load the sound into more 
than one sound buffer, or you can duplicate the sound buffer. T he first method is wasteful, especially if 
you have a large number of sounds. D igital sounds can take up a lot of space— in some cases, more than 
graphics can. 


D uplication is a good alternative. W hen you duplicate a sound buffer, you do not make an independent 
copy. A duplicated buffer points to the exact same memory that the original does, so if you lock the dupli- 
cate and modify the contents, you'll get the same change if the original is played. R ight after duplication 
the new buffer has the same parameters (volume, pan, frequency) as the original. T hese parameters can be 
changed. 


To duplicate a sound buffer, you use iDirectSound: :DuplicateBuffer: 


HRESULT IDirectSound: :DuplicateSoundBuf fer ( 
LPDIRECTSOUNDBUFFER lpDsbOriginal, 
LPLPDIRECTSOUNDBUFFER lplpDsbDuplicate 

ys 


T his returns ps ox if successful. T his method increases the original buffer's reference count, so you can 
Safely release it and rest assured that the duplicate will still function properly. 


//duplicate buffer 
lpds-»DuplicateSoundBuffer(lpdsb,&lpdsbcopy): 


You may wonder why in the world you would ever need more than a single copy of a sound. In many (or 
even most) cases, you probably dont. H owever, as with oft-repeated sounds such as a gun firing, you may 
want to have two copies or even more. 
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USING NAV FILES 


lve been talking about sound and WAV files the whole chapter long, and at last, l'm going to show you 
how to load them. WAV files are the final bridge between you and making your program come alive with 
digital sound! Before | discuss W AV files let's take a brief detour and explore how to open and read from 
files theW IN 32 way (I'm not a big fstream fan). 


USING HANDLES то Do Fite OPERATIONS 


W eve spoken at length about the various types of HANDLES prevalent in W IN 32 programming. File access 
is also done using a HANDLE. In order to do any sort of sequential access of a file you need to know only 
four functions: CreateFile, WriteFile, ReadFile, and CloseHandle 


For your purposes (loading from aW AV file), these four functions will get the job done. 1 5 take a quick 


look at them. 

CREATEFILE 

Use CreateFile to either create a new file or open an existing one. 

HANDLE CreateFile( 
LPCTSTR IpFileName, // file name 
DWORD dwDesiredAccess, // access mode 
DWORD dwShareMode, // share mode 
LPSECURITY ATTRIBUTES lpSecurityAttributes, // SD 
DWORD dwCreationDisposition, // how to create 
DWORD dwFlagsAndAttributes, // file attributes 
HANDLE hTemplateFile // handle to template file 


E 


T his returns a handle to the file. If the function fails, the return value is INVALID_HANDLE_vALUE. Table 
8.9 explains the parameters. 
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Table 8.9 CreateFile Parameters 
CreateFile Parameter Purpose 


lpFileName The name of the file 
dwDesiredAccess Access mode desired (GENERIC READ Or GENERIC WRITE) 
dwShareMode Share mode 


IpSecurityAttributes Pointer to security attributes 
dwCreationDisposition How the file is to be created 
dwFlagsAndAttributes File attributes 


hTemplateFile Template file 


CreateFile has a bunch of parameters, most of which you wont use: 


= 1pFileName will contain a string with the name of the file and a relative path. 

и dwDesiredAccess Will be either GENERIC READ ОГ GENERIC WRITE, depending on which you 
want to do. 

= dwShareMode Will be 0. You are greedy, and you dont want to share your sound files with anybody. 

= lpSecurityAttributes points to security junk, which you dont care about, so you'll pass NULL. 

= dwCreationDistribution will either be CREATE ALWAYS (when making a new file) or OPEN. EXISTING 
(when opening an old one). 

= dwFlagsAndAttributes should always be FILE ATTRIBUTE NORMAL. 

= hTemplateFile ме arent discussing, so pass NULL. 


WRITEFILE 
T his function is used to write data to the file. 
BOOL WriteFile( 


HANDLE hFile, // handle to file 
LPCVOID lpBuffer, // data buffer 
DWORD nNumberOfBytesToWrite, // number of bytes to write 


LPDWORD lpNumberOfBytesWritten,  // number of bytes written 
LPOVERLAPPED lpOverlapped // overlapped buffer 
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T his returns nonzero on success. Table 8.10 explains the parameters. 


Table 8.10 WriteFile Parameters 


WriteFile Parameter Purpose 

hFile Handle to the file to which you are writing 
lpBuffer A buffer that contains the contents to be written 
nNumberOfBytesToWrite The number of bytes in the buffer 


1pNumberOfBytesWritten A pointer to a DWORD that contains the number of bytes 
actually written 


lpOverlapped Ignore. Pass NULL. 


Its important to check the value returned in 1pNumberOfBytesWritten against the number that you told 
it to write in order to check for errors. 


READFILE 
ReadFile IS used to read data from a file. It looks quite a bit like writeFile. 


BOOL ReadFile( 
HANDLE hFile, // handle to file 
LPVOID lpBuffer, // data buffer 
DWORD nNumberOfBytesToRead, // number of bytes to read 
LPDWORD lpNumberOfBytesRead, // number of bytes read 
LPOVERLAPPED Тр0уегТарреа // overlapped buffer 
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T his returns nonzero on success. T able 8.11 explains the parameters. 


Table 8.11 ReadFile Parameters 


ReadFile Parameter Purpose 
hFile Handle to the file from which you are reading 
pBuffer Buffer into which data from the file will be stored 
nNumberOfBytesToRead N umber of bytes in the buffer 
pNumberOfBytesRead A pointer to a DWORD that will be filled with the actual num- 
ber of bytes read 
pOverlapped Ignore. Pass NULL. 


As with writeFile, be sure to check the value returned in 1 pNumberOfBytesRead. 


CLOSEHANDLE 
T he simplest of them all, стоѕенапате closes the file. 


BOOL CloseHandle( 
HANDLE hObject // handle to object 
у 


T his returns nonzero on success. hObject is the file handle. 


THE STRUCTURE OF A ІЛІНУ FILE 


№ ow that you can read data from a file it's almost time to do so. But first (you saw that one coming), 
lets talk a little bit about the structure of aWAV file T hen, | promise we'll get to the actual loading of 
the file 


T heWAV fileformat is based on the RIFF format, which was developed to allow many types of files to 
use the same format— even files with radically different purposes. N ot surprisingly, the first four bytes of 
aWAV file contain the string "RIFF".T he next four bytes contain the length of the rest of the file. T hese 
eight bytes make up what is called the RIFF hade. Т his is common to any file with the RIFF format. 


N ow we start getting into the particulars of theW AV file itself. T he next four bytes contain the string 
"WAVE." T his is what identifies the file as aW AV file T he remainder of the file consists of data “chunks.” 
Figure 8.8 shows a graphical version of the contents of a chunk. 


DirsecrTAhouNn СЕЗ 


You are concerned with exactly two types of chunk: the “fmt” chunk (there is а space after the t) and the 
"data" chunk. T he "fmt" chunk contains information about the format of the sound, and the fields corre 
spond, for the most part, to the members of wAVEFORMATEX.T he "data" chunk contains the raw audio 
data that you put into the buffer after you have locked it. 


T here are more than just these two chunks, but for the purpose of loading aW AV file, these are the only 
two that are of any use. In all of theWAV files I've ever worked with, the "fmt" chunk always comes first, 
and, in most cases, the “data” chunk comes immediately thereafter. 


LOADING A ІЛІНУ FILE From DIS 
As with the bitmap loader back in Chapter 3, | ve written a class to do the WAV file loading: 


//wave loader class 

class CWAVLoader 

{ 

private: 
//format 
LPWAVEFORMATEX lpWfx; 
//data chunk 
UCHAR* ucData; 
//\ength of the data chunk 
DWORD dwDataLength; 

public: 
//constructor 
CWAVLoader(); 
//destructor 
~CWAVLoader(); 
//get data lengt 
DWORD GetLength 
//get data pointer 
ОСНАВ* GetData( 
//get pointer to format 
LPWAVEFORMATEX GetFormat(); 
//load from а file 
void Load(LPCTSTR lpszFilename); 
//destroy buffer 
void Destroy(); 


Ke en 


ISOMETRIC GAME PROGRAMMING wiItTH, DIRECTX 7,0 


//Тоаа from a file 
void CWAVLoader::Load(LPCTSTR lpszFilename) 


{ 


T he constructor does very little— it simply makes sure that all of the data members are cleared out. T he 
destructor just calls Destroy, which performs any necessary cleanup. T he cet members retrieve the data 
stored in the class. T he main job of the class is done by Load: 


//destroy any old buffer 


DWOR 


DWOR 


//da 
UCHA 


HAND 


Read 
Read 
Read 
//ch 
bool 


while(!done) 


{ 


of chunk 


Destroy(); 
//four character buffer 
char Buffer[5]; 
Buffer[4]-0; 

//read length 

D dwNumRead; 

// length variable 

D dwLength; 


FILE 
FILE 


unks 
done= 


Read 
Read 


ucTe 


ta buffer 
R* ucTemp; 
//open a handle to the file 
LE hfile=CreateFile(lpszFilename,GENERIC_READ, 


_SHARE_READ, NULL, ОРЕМ ЕХІЅТІМС, 
_ATTRIBUTE_NORMAL, NULL) ; 


File(hfile,Buffer,4,&dwNumRead,NULL);//"RIFF" 
File(hfile, &dwLength,sizeof(dwLength),&dwNumRead,NULL);//length of file 
File(hfile,Buffer,4,&dwNumRead, NULL) ;// "WAVE" 


false; 


File(hfile,Buffer,4,&dwNumRead,NULL) ;//chunk header 
File(hfile,&dwLength,sizeof(dwLength) ,&dwNumRead,NULL);//length 


mp=new UCHAR[dwLength]; 


Read 
//de 
if(s 
{ 


File(hfile,ucTemp,dwLength, &dwNumRead, NULL) ; 
pending on the chunk header, do something 
trcmp("fmt ",Buffer)==0) 


//format chunk 
//allocate format 
lpWfx-new WAVEFORMATEX; 
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//clear out format 

memset (lpWfx,0,sizeof(WAVEFORMATEX)); 
//copy from buffer 

memcpy (lpWfx,ucTemp,dwLength) ; 


} 
if(strcmp("data",Buffer)--0) 
{ 
//data chunk 
//allocate data buffer 
ucData=new UCHAR[dwLength]; 
//copy length 
dwDataLength=dwLength; 
//copy buffer 
memcpy (ucData,ucTemp,dwDataLength) ; 


//we are done, and need no more chunks 
done=true; 
} 


delete ucTemp; 


} 
//close the file 
CloseHandle(hfile); 


USING CWWHVLOADER TO LOAD FROM A 
FILE то A DIRECTSOUNDBUFFER 


Load up IsoH ex8_2.cpp. It's our favorite bouncing ball demo again! Т his time, though, we are using 
IDirectSoundBuffer and CWAVLoader. 


//declarations (global) 
//sound manager 
LPDIRECTSOUND lpds; 
//buffers 
LPDIRECTSOUNDBUFFER lpdsb[2]; 
//setup (Prog Init) 
//\oad wav file 
CWAVLoader wav; 
wav.Load("bounce.wav"); 
//set up sounds 
DirectSoundCreate(NULL,&lpds, NULL) ; 
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//set coop level 
lpds->SetCooperativeLevel (hWndMain, DSSCL_NORMAL) ; 
//set up buffer description 

DSBUFFERDESC dsbd; 
emset(&dsbd,0,sizeof(DSBUFFERDESC) ); 

//size 
dsbd.dwSize-sizeof(DSBUFFERDESC) ; 


/flags 
sbd.dwFlags=DSBCAPS_LOCSOFTWARE; 
/length and sound format 
sbd.dwBufferBytes-wav.GetLength(); 
dsbd.lpwfxFormat-wav.GetFormat(); 
//create buffer 
lpds-5CreateSoundBuffer(&dsbd,&lpdsb[0], NULL) ; 
DWORD buflen,buflen2; 
void* bufptr; 
//lock entire buffer 
lpdsb[0]-»Lock(0,0,&bufptr,&buflen, 
NULL, &buflen2,DSBLOCK_ENTIREBUFFER) ; 
//copy from wave loader to sound buffer 
emcpy(bufptr,wav.GetData(),wav.GetLength()); 
//unlock the buffer 
lpdsb[0]-»Unlock(bufptr,buflen, NULL, buflen2) ; 
//duplicate the sound 
lpds-»DuplicateSoundBuffer(lpdsb[0],&lpdsb[1]):; 
//clean up (Prog. Done) 

//clean up sounds 

if(|pdsb[1]) 

{ 


/ 
d 
/ 
d 


lpdsb[1]->Release(); 
lpdsb[1]-NULL; 


} 
if(lpdsb[01) 
{ 
lpdsb[0]-»Release(); 
lpdsb[0]-NULL; 


} 

//clean up sound manager 
if(lpds) 

{ 
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lpds->Release(); 
lpds-NULL; 

} 

//The "bounce" (Prog Loop) 

//bounds checking 

//\eft side 

if (ptBallPosition[Lindex].x<=0) 

{ 


ptBallVelocityLindex].x=abs(ptBallVelocityLindex].x); 
lpdsbLindex]->Play(0,0,0); 
} 
//top side 
if (ptBallPositionLindex].y<=0) 
{ 


ptBallVelocityLindex].y=abs(ptBallVelocityLindex].y); 
IpdsbLindex]->Play(0,0,0); 


} 

//right side 

if(ptBallPosition[index].x»-(int)dwDisplayWidth-gdicBall.GetWidth()) 

{ 
ptBallVelocityLindex].x=-abs(ptBallVelocityLindex].x); 
IpdsbLindex]->Play(0,0,0); 


} 

//bottom side 

if(ptBallPositionLindex].y>=(int)dwDisplayHeight-gdicBall.GetHeight()) 

{ 
ptBallVelocityLindex].y=-abs(ptBallVelocityLindex].y); 
lpdsbLindex]-5P1ay(0,0,0); 


As you can see, two sound buffers are created, one for each ball. О ne is loaded from theW AV file, and the 
other is a duplicate. n reality, you would probably want to make more. O ccasionally a ball will bounce off 
one wall and then almost immediately bounce off another wall. W ith only one buffer per ball, this would 
mean that only one bounce is heard if the time between bounces is shorter than the sound itself. Take into 
consideration situations like this when deciding how many copies of a sound to make— if you dont make 
the copies at design time, they will have to be added during development or even during beta. 


| EH | ISOMETRIC GAME PROGRAMMING ulrH DIRECTX 7,0 


THE DSFUNCS LIBRARY 


Like the D D Funcs library | showed you in Chapter 6, the D SF uncs library is meant to help you avoid 
repetitive tasks necessary during the creation of sound buffers. T here isnt much to this library. 


LPDOSB_LOADFROMFILE 


LPDIRECTSOUNDBUFFER LPDSB_LoadFromFile(LPDIRECTSOUND lpds,LPCTSTR lpszFileName); 


T his returns a new sound buffer. 1pds is a pointer to an [DirectSound object that is used to create the 
new buffer. 1pszFileName is the file name of theW AV file that you want loaded into this buffer. 


LPDOSB_ RELEASE 


void LPDSB Release(LPDIRECTSOUNDBUFFER* Iplpdsb); 


T his returns nothing. It performs а safe release on an [DirectSoundBuffer. 1p1pdsb іѕ a pointer to 
LPDIRECTSOUNDBUFFER. N ote that | didnt wrap up DuplicateSoundBuffer or the SetVolume, SetPan, 
ОГ SetFrequency functions. T hey are simple enough in their current form. 


EMPOWERING THE USER 


It may not seem that there too many places where you can empower the user as far as sound is concerned. 
T he empowerment is not nearly as obvious as it is with D irectD raw. T he most essential sound empower- 
ment you can give your users is the ability to turn sound off. Yes, your sounds are spiffy and they really add 
to the flavor of the game, but face it: at some point, they will get repetitive and begin to annoy even the 
most insesitive user. So make at least a "sound off” option. By doing so, your users can play at work and 
get their coworkers addicted to your game. 


T he second user empowerment for sound is the ability to set the volume. D epending on the game this 
may be one, two, or three different volumes. U sually, sound effects (SF X), voice (МОХ ), and music 
(MUS) have different volumes. If you have a sufficiently small number of sounds, you can get away with 
having only one or two of these. T his empowerment isnt nearly as important as "sound off,” but it is 
nonetheless important. It is a feature that your users will be expecting. 


DiRecTSOUND 219 | 


SUMMARY 


DS's capabilities far exceed what little weve covered here. Т hose capabilities include 3D sound, using noti- 
fication, syncing sounds, and DirectM usic. | could never hope to do justice to all of these іп a short intro- 
ductory chapter. 


Following are a few things to remember: 


= To play sounds theW IN 32 way, you use PlaySound. 

= To use the capabilities of DirectSound, you create an IDi rectSound object, much in the same way you cre 
ated an IDirectDraw object in D irectD raw. 

= Digital sounds are stored in Di rectSoundBuffers and are created by using 
IDirectSound: :CreateSoundBuffer. 

= Depending on how you set it up, you can control a sound's volume pan, or frequency to get various effects. 

= |f you need more than a single copy of aWAV file it is best to use Пир! icateSoundBuffer rather than 
loading the same sound multiple times. 


Е = 


m 2 
se | [ne Mu 


CHAPTER 9 


+1 L1 : i or a — 


GAME DESIGN 
THEORY 


B THE INTANGIBLE NATURE 
оғ GAMES 


а DESIGNING A GAME 


g FROM THEORY TO PRACTICE 


Game DESIGN THEORY 221. 


his is the last chapter in Part |, but | think it is the most important. T his chapter has nothing to do 
with W IN 32, graphics, or sound. It has to do with the design of the game itself. Game design the 
ory isone of my favorite topics; | could talk about it all day. 


Al DEFINITION OF GAME 


Let's start with a definition of what makes а дате. А game is a structured activity not generally related to 
survival. T his definition is a little vague, but it's the most concise! could come up with. Let's take it apart: 


= Structured. T he meaning of "structure" here denotes a set of formalized rules that are essential for a game's 
existence. 

= Activity. [п order to play a game you must be doing something. 

= Not generally related to survival. Granted, Russian Roulette is rdated to survival, but most other games 
are not. 


THE INTANGIBLE NATURE OF GAMES 


Please note that | speak of rules and activities, but | make по mention of boards, tokens, play money, or 
any other sort of marker whatsoever. T hese are not required to have a game. Some games, especially athlet- 
ic ones, do indeed require the use of the equipment associated with them. Basketball needs a ball that 

can be bounced and something to serve as a net. Baseball needs а stick and a ball and four bases, but any- 
thing can serve as the bases (when | was a kid, we often used trees). Figure 9.1 shows some game-playing 
paraphernalia. 


Figure 9.1 


A variety of game equipment 
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So, the game is not the stuff with which you play the дате; you may have balls and bats and hoops and 
chess pieces and a chessboard, but these things are not the game. Т he game is contained totally within your 
head. T he pieces positioned on the board or the players positioned on the bases just keep track of the 
games current state. W hen playing the game, you attempt to manipulate the games state in your favor. T he 
manner in which you manipulate the games state is called a game mechanic. 


T he game mechanic is governed by the rules. T he rules define the possible game states that are legal, as 
well as what game mechanics are available to you to manipulate the game state. W hen all of these possible 
game states are taken together, they are the game state space (that is, all possible moves after a given game 
state). 


At the start of the game the game state space can be very large (enormous, when playing games such as 
chess), or nearly impossible to determine in athletic games such as basketball or baseball. As play progress- 
es, the game state space diminishes until the game reaches completion, at which time the game state space 
is empty. T his is called the final game state or the ed game. 


In some games, it is impossible to determine the end game until the absolute end of the game has been 
reached. М any games involving cards are this way, as аге most games of chance. In most games, though, it 
becomes more and more evident how the game will end as the end approaches. Chess is a good example of 
this, as is backgammon. In no game is it ever certain from the beginning how the game will end up. 


Way ІЛЕ PLAY 


Games are played in every culture on earth; and if we should ever encounter an alien species, | expect them 
to bring some good games with them, or else they can just go home.T he question of why we play games 
remains. Both you and |, as game programmers, play a lot of games. We would not have been interested in 
making them if we didnt like playing them. It sure isnt the game programming pay that motivates us! 


| believe it's in our nature to be competitive with the other members of our species (but, paradoxically, 
cooperative at the same time). Ever since the days of cavemen, weve been competing for good hunting 
land, good shelter, and other natural resources. 


In fact, it's easy to imagine the first game (or at least a candidate for the first game)— target practice. 

T hrowing spears at trees to improve accuracy would help the ability to hunt, and thus would help the 
hunter and the clan survive. As technology improved, and people learned to raise crops and cultivate live 
stock, hunting for food became less important, so target practice with spears became non-survival-related. 
Perhaps people came up with a scoring system, using something similar to the archer's target. Target prac- 
tice games survive to this day, in several forms. Darts, archery, lawn darts, and even horseshoes could date 
back to this game. 
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T he target practice example doesnt explain our personal reasons for playing games, but it does illustrate 
how games can come about. O ur reasons for playing games change as the game develops. T he cavemen 
played a spear throwing game to hone their hunting skills. After hunting was no longer as important, the 
game continued because it was fun. It allowed people to compare skill levels. 


So, there are several reasons that we play games— we develop skills, solve problems, enjoy the thrill of the 
unknown outcome, and test our mettle against another. M ainly, we play games because they are fun, and 
different games are fun for different reasons. 


COMPUTER GAMES 


Computers have been used to play games almost since the moment of their inception. N ow we have force 
feedback joysticks, as well as graphical capabilities that in the coming years may even mimic real life, and 
sound capabilities that already do. 


Computers are uniquely suited for playing games. W ith a computer to implement the rules and represent 
the game state on-screen, we dont have to have a board or tokens. As computers have gotten faster, more 
and more complex rules have been used; some or all of these rules can be cleverly hidden so that the player 
needs only a dim awareness of them. (Yes, in computer role-playing games, you know that when you try to 
hit a monster, there is some sort of randomized skill check. Н owever, you dont actually care about the 
roll, just whether or not you hit. T his is what | mean by rule hiding.) T his is called game mechanic encapsulation. 
M ost modern computer games would not be fun if they were played on a board with tokens and markers, 
because of the sheer number of game mechanics. 


GAME ANALYS15 


[п order to be a good game designer, you should have a solid grasp of how other games are designed. 
Good games are balanced, meaning that they are not unfair. Fairness in a game is hard to realize. In a com- 
puter role-playing game, as the characters that the player controls become more powerful, they should be 
met with more powerful foes. If the foes get too tough too quickly, the player will become frustrated and 
give up. If the foes do not become tougher quickly enough, the player will become bored and again will 
quit playing, Sustaining the challenge while still having a victory condition is important in these progres- 
sive types of games. О ther games, like most board games and most sports, are not progressive. T he chal- 
lenge is the same throughout the game, and incremental difficulty is not required. 


As an exercise, take your favorite sport or board game, and write down its rules. W rite down these rules as 
though you were explaining them to someone who has never heard of this game and is from a totally dif- 
ferent culture. Even in the most simplistic of games, a description like this can take up many pages. For 
example, if you were describing baseball, you would have to define the meaning of bases, baseballs, bats, 
and teams. T hen youd have to talk about innings and outs and balls and strikes, defining each as you went. 
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It would quickly become quite a large description, especially if you went into R BIs, batting averages, 
and so on. 


You should do this kind of analysis on computer games as well. M any of the game mechanics are encapsu- 
lated, but you should be able to at least hazard a guess as to how they are accomplished. 


DESIGNING A GAME 


After you've analyzed a number of games (and you'll notice that when looking at a game analytically, it has 
a different feel than when you're just playing for fun), you сап get down to the serious business of design- 
ing new ones. 


A warning: there really arent any "totally original" games any more. M ost games these days are just varia- 
tions on games of the past, or games from a different point of view, or an older game with a new twist. 
Game design in the modern world pretty much consists of variation on a theme. But dont be dismayed. 
You dont haveto done other games in order to be a game designer and game programmer. 


D uring your game analysis, presumably you looked at several games from the same genre for which you 
want to write. You should have good data concerning how these games are put together and what their 
game mechanics are. You can now do a comparative analysis of what makes these games effective. 


If you find an overwhelming commonality between the games you analyze, it probably means that the fea- 
ture is expected for the genre T his doesnt mean you should automatically include it in your game. It does, 
however, mean that you should take it under most serious consideration. Is doing it this way the absolute 
way to do it, or is there another way, just as effective or even more effective? Be skeptical about everything, 
and question everything. T his is not to say that you should reject everything that came before, but just to 
point out that institutions should always be scrutinized. 


W hen you notice a feature that is included in some games you have analyzed but not in all of them, you 
should question whether the feature is appropriate to your game. It might help the game, it might do noth- 
ing for the game, or it might hurt the game. Trying to anticipate potential problems with a feature now, at 
design time, is much more productive than having to rip out code later. 


If it hurts the game, definitely leave it out, unless you feel you can come up with a modification that fixes 
the problems. If a feature does nothing for your game either way, you have a few options. You can leave it 
out completely, or you can make it optional. N ot all features can be made optional (a good example in 
strategy games is the ability to do tactical battle screens, or just let the computer auto-resolve them). Y ou 
should never just "throw it in.” By doing so, it is evident that you dont care about your game, and the users 
will see this. 


If you find a feature that is in only a few or just one or two of the games you analyzed, you should seri- 
ously question whether or not to include it. M ost times, this means that the feature was haphazardly done 
and probably isnt very good. 


Game DESIGN THEORY Е 


M y main point here is that when designing а game it is very important to think about the features you 
want. Beginning game developers tend to run into problems with their project getting too large, too fast, 
because they just started writing the game and adding features as they went. M ost of the time, this winds 
up being a project that is never completed (as! well know. .. I've failed to complete hundreds of games). 


At the end of analysis, you should have а good list of features that you want in your game, and a list that 
you definitely dont. You should keep both of these lists, because they will help you as you develop your 
initial concept and as you flesh out that concept. 


INITIAL CONCEPT 


You have an idea for а game. Great! Actually, l'm about to show you that you dont have an idea for a 
game, you have a pre-idea. 


Your idea can probably be stated in about one or two sentences, and maybe as much as a whole paragraph. 
Write it down. If anywhere in your game idea you have the words "like X ,” where X is the name of a game 
currently on the market, scratch out the idea and rewrite it so that it doesnt compare itself to another 
game. T his is important. You are not a lemming! Your game will not be the other game, nor a done of it. 
It will be a work that stands on its own! Oh, and did | forget to mention have a good, positive attitude about your- 
sdf, your skills, and your idea? 


If applicable, you may want to develop a little bit of a back story. A back story is the reason that the game is 
being played (at least, the reason in the alternate universe within the computer). In strategy games, it tends 
to bean epic struggle between forces, or the fight of a small band of settlers to survive and grow. T here is 
a story in there somewhere— find it. Н owever, dont go into too much detail on the back story right now. 
Get the main ideas on paper, and flesh it out later. Sure, you could write a novel about the back story, but 
youd never get your game done! 


FLESHING 1Т OUT 


Take your idea and apply the results of your comparative analysis to it. Pick which aspects will be included 
and which wont. Find features that fit with your game idea and your back story. Feel free to add more fea 
tures that you think are needed, but remember to rigorously analyze their appropriateness later. 


O nce you have chosen which features you'll include, you should start drawing pictures (they dont have to 
be works of art...simple sketches will do) that are sort of a “story board” of your game. Put in as much 
descriptive detail about your game as possible. Explain how you will implement the various features that 
you have picked for your game. 


Break it down, flesh it out, and put in as much detail as you can. W hen you have finished, congratulations! 
You have a design document. 
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FROM THEORY TO PRACTICE 


ОК... 50 far I've been talking about vague theoretical concepts and using ambiguous terms like "feature" 
T he difficulty with discussing game design is that it encompasses so many aspects, and various genres have 
different ways of dealing with them. 


Let’s pick some genres and look at them. 


THE ARCADE/ACTION GENRE 


T his genre includes such games as Pac М an, Space Invaders, A steroids, С entipede Joust, G auntl&, and many more 
too numerous to mention. M ainly, these games are concerned with wave upon wave (with incremental dif- 
ficulty) of “bad guys” or obstacles. Table 9.1 outlines the main point in each of the games listed. 


Table 9.1 Some Arcade Games andT heir 


Underlying Ideas 
Game Idea 
Pac-Man Gobble all the dots and avoid ghosts 
Space Invaders Shoot all invaders before they land 
Asteroids Destroy all asteroids or ships before they destroy you 
Centipede Destroy a number of centipedes and other enemies before they kill you 
Joust Kill all enemies before they regenerate and before they kill you 
Gauntlet Kill enemies and collect power-ups while trying to find the exit 


All of these games have "hostiles" — whether they be asteroids or invaders or ghosts. T hese must be avoid- 
ed or killed, or they will kill you (whether consciously through an Al, or just by wandering around like the 
asteroids). M ost of these games have some sort of power-up system. At the very least, at various score lev- 
els you gain an extra “life” In Pac-M an, the power pills turn the tables on the ghosts. In Gauntlet, keys and 
potions make your job easier. 
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T hese games also all have a “wave” or “level” structure to them. W hen one level is finished, the next level 
is loaded. С etipede is the only exception: the waves run right into one another without any sort of break 
(the colors just change). 


N ow that you have a few topics to analyze, let’s take a closer look at them and ask the big questions. 


ARE HOSTILES NECESSARY? 


H ostiles are the primary motivator in all of these games. T hey provide the ability for the player to fail. 

N otice how most of these games cannot be "won"?T his is so mainly to keep frantic teen-agers pumping 
quarters into the machines, but it also demonstrates that you don't have to be able to “win” for the game 
to be fun. О ther rewards will suffice, such as getting to the next level, or getting a high score. If you want- 
ed to replace hostiles in a game, you would have to provide a different way for the player to fail. D oing so 
would take you out of the arcade/ action genre, so having a hostile is definitely a fundamental aspect of 
having a game of this genre. 


ARE POWER-UPS NECESSARY? 


All of these games (except G auntie) have at least one power-up— the extra life after so many waves or levels 
or after a certain score. О ther power-ups, like Рас M an's power pellet, or the potions and keys іп С auntld, 
depend entirely on the specific game. W ithout the power pellets, Pac М ап would bea lot harder to 

play... maybe too hard. б auntle keys are absolutely essential, because part of the challenge is to find enough 
keys to get through all the doors. T he potions in Gauntl& arent absolutely necessary, but they relieve (for a 
moment) the stress of being embroiled in a battle, so they are appropriate to the game. 


ARE WAVES OR LEVELS NECESSARY? 


Levels or waves help break up the play alittle bit, but they arent absolutely required. You can achieve 
incremental difficulty without having levels, but using levels makes implementing that incremental 
difficulty easier. 


As you can see, weve pretty much nailed down the action/ arcade genre. Waves, power-ups, and hostiles are 
key elements. If you were to design a game for this genre, you would want to carefully consider how you 
wanted to implement these things, or if you wanted to find an alternative. 


ISOMETRIC GAMES 


Isometric games usually fall into a few genres: computer role-playing games, turn-based strategy games, 
real-time strategy games and simulations, and board/ puzzle games. 
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[ е5 take a look at the turn-based strategy game subgenre. (Turn-based strategy games still belong to the 
strategy game genre, but the implementation is much different from а real-time game or simulation.) А few 
of the games in this subgenre include C ivilization 11, C ivilization: С all to Power, M aster of O rion 11, Imperialism 11, 
and Alpha C etauri. 


= |n all of these games, you start out with a limited number of units (usually only one or two), and from this, 
you have to build a grand empire Some games, however, have a "scenario" mode, in which a situation is set 
up for you, and you have certain objectives that you have to reach. 

и |n all of these games, the units available to you depend on what technologies you possess, and these games 
have ways to assign the technologies you are researching. 

и T hese games, for the most part, have resources that you have to discover and exploit, and you have to improve 
the land or a city or colony to better make use of these resources. 

= T he goal of most of these games is to subdue all of your computerized opponents, either diplomatically, 
through military action, or by completion of a task before they complete it. 


T heres alot more to turn-based strategy games, but this is a good sampling. 


Іш STARTING OUT THE PLAYER WITH ONLY A FEW 
UNITS NECESSARY? 


It's not necessary to start out everybody as a weakling. Н owever, except where the player has selected the 
“impossible” option or has chosen to play a scenario, it is а good idea to start out all the players (human 
and computer) as approximately even. T his is one of the important aspects of turn-based games. T he play- 
er gets to take his single unit and create an empire with it. 


ARE TECHNOLOGY AND RESEARCH NECESSARY? 


Technology and research enhance the replay value W ithout technology to research, all things are available 
to the player at the beginning. T his might be what you want. Н owever, including technology and research 
in the game promotes careful planning and forethought on the part of the player. 


T his is not to say that having technology and research in а game is essential to the genre. In fact, it seems 
that every game maker just throws then in. | remember playing the old Avalon H ill strategy board games 
(with the hex grids), and very few of then had technology and research. 


WHAT SORT OF WIN CONDITIONS ARE NECESSARY? 


In most types of games, an absolute “win” condition is not necessary. In strategy games, however, some 
sort of win condition is necessary, whether it is the construction of some device before any of your oppo- 
nents, the elimination of your opponents, or whatever. Commonly, strategy games have a scoring system 
based on any number of things— level of technology, size of army, population, and so on.T his scoring 
system lets you rank players after they have quit the game, and you can then build a “hall of fame” list. 
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As you can see, quite a bit of thought goes into designing a game You have to ask yourself the big ques- 
tions. T hat's really what this chapter is about... thinking. Sure, you could just take a game you like and 
make something that looks and plays like it (and many beginners want to do just that). T hat's not neces- 
sarily a bad idea, but too close of a copy won't do much for your game programming image. 


EMPOWERING THE USERE GIVING 
THOUGHT TO THE USER INTERFACE 


T hroughout the game design process, you should keep user enpowerment in mind. W hen designing 
screens with which the user will interact, you should strive to make the most intuitive interface you can. 
T his means menus and buttons and other user interface components. It also means character selection, 
object manipulation, and just about everything that the user can do in the game. Putting a good deal of 
thought into this topic will be of great пар later, when it comes time to actually make your game. 


Also, you should determine which of your games features are optional. Customizing game play is a great 
way to empower your users. | once played a game that had an option screen with exactly two options: 
music on/ off and sound on/ off. T hat was the total of the options (and yes, it was a full-screen option 
panel)! In my opinion, that is unacceptable. 


If you plan to have your game sell in more than one language, you'll probably want to use icons on your 
buttons instead of text. D oing so is fine, but be sureto put some sort of textual tool tips on the screen if 
the mouse hovers over these icons for a few seconds. 


T his brings meto something ese. . . your game's learning curve W hen | buy a game, | want to plop the 
CD in the drive, dose the door, install it, and play it. N otethat | did not mention "read the manual" or 
"read the help file" anywhere in this process. | want to play, and | want to play now! M ost game players are 
like this... many of them never read the manual. N ot all games can accomplish the “just sit down and 
play” intuitiveness, however. | mperialism 11 by SSI is one of these It's a turn-based strategy game that at first 
seems difficult to play, but playing the tutorials shows you that it's actually not so hard and, in reality, is a 
fun game. If you can avoid requiring tutorials or reading manuals or help files, though, do so. 


On the other hand, | hate games without adequate documentation. You should have a good help system 
for your game, even if your player never uses it. You should have strategy tips of some kind if applicable. 
D ont give everything away, but do give a nudge in the right direction. 


A Few NoTes ABOUT CONTROLS 


If you use keyboard controls, use the arrow keys or the numeric keypad. If you use the keypad, try not to 
use the 5 key for anything. T he Esc key is for canceling something or exiting something. T he spacebar is a 
big key, and you can probably find a use for it. F 1 is for help. If you have controls for a number of related 
purposes, try to use a row of keys rather than scattering about the keyboard. 


Е: ISOMETRIC GAME PROGRAMMING wItTH, DIRECTX 7,0 


W hen using mouse controls, the left button is for the primary action, and the right button is for the sec- 
ondary action. М ost of the time, the primary and secondary actions can be determined by what the mouse 
is currently pointing at. If it's pointing at a monster, attack. If it’s pointing at an item, pick it up. If it's 
pointing at a door, open it. 


Also, when the mouse is over something, provide a visual clue— a highlight, a different cursor, or just 
something that lets the user know that the mouse is over something that can be interacted with. It's also 
not a bad idea to have a tool tip or some text in a status bar when the mouse hovers over an object. 


Finally, in games that take up more than the screen, it is traditional to scroll through the map when the 
mouse is on the edge of the screen. Also, there should probably be a mini-map of some sort, with a rec- 
tangle showing where the current view is. 


MAKING A REAL GAME 
| ve included a sample game as IsoH ex9_ 1.срр. It incorporates most of what we have covered in this first 
part of the book. 


T he game is Breakout, something I'm sure you've played before. Т he idea is to use a paddle to bounce a ball 
and strike bricks. W hen all of the bricks from one leve are destroyed, the game advances to the next level 
(which looks just like the first level). Figure 9.2 shows what this game looks like. 


Figure 9.2 
The look of IsoHex9 1.cpp 
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T he graphics are less than dazzling, | know. (1 spent about 15 minutes with Paint Shop Pro to make 
them.) T he main reason for including this demo is to show you some of the basic ways you can accom- 
plish tasks in a game program. 


T he controls are pretty simple you move the paddle with the mouse, and a left-click starts things. T here 
are no title screens or option screens. T here is very little user empowerment (hey, it’s just a sample). T here 
are plenty of sounds— a bouncing noise (borrowed from the boucing ball demo), a different brick hit 
noise for each color of brick, a losing sound, a winning sound, and a few voice sounds for when you hit 
more than 10 bricks between paddle hits. Т hese sounds all come from either my voice or my Yamaha Кеу- 
board. 


GAME STATE 


IsoH ех9 1.срр has a number of global variables. T he first of these is game state. W hile the game state is 
Kept track of by all the variables in the program (score, paddle and ball positions, number of bricks left), 
there is amain game state— playing, waiting to play, game over, win, death, and so on. 


| keep track of these using an enum and a variable. 


//game states 

enum GAMESTATE 

(GS START,GS STARTWAIT,GS PLAY,GS DEAD,GS RESET,GS WINLEVEL,GS LOSEGAMEJ]; 
//main game state 

GAMESTATE GameState-GS START; 


| also could have managed these with a number of consts Or #defines, but in an enum, | know that | wont 
duplicate a number accidentally and have to track down a bug for five hours. It's mainly a matter of per- 
sonal preference. 


T he GameState variable is processed in Prog Loop: 


void Prog Loop() 
{ 
switch(GameState) 
{ 
case GS_START: 
{ 
dwScore=0; 
dwLives-3; 
SetUpGame(); 
GameState=GS_STARTWAIT; 
}break; 
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case GS_STARTWAIT: 
{ 


ShowBoard(); 
lpddsprime-»Flip(NULL,DDFLIP WAIT); 
}break; 
case GS_PLAY: 
{ 
//limit frame time 
DWORD dwTimeStart-GetTickCount(); 
//move ball 
MoveBall(); 
//show board 
ShowBoard(); 
//show frame 
lpddsprime-»Flip(NULL,DDFLIP WAIT); 


//wait for 10 ms to elapse 
while(GetTickCount()-dwTimeStart«10); 
}break; 
case GS_DEAD: 
{ 
dwLives-; 
if(dwLives) 
{ 
GameState=GS_RESET; 


GameState=GS_LOSEGAME; 


break; 
case GS_RESET: 
{ 
ResetGame(); 
GameState=GS_STARTWAIT; 
break; 
case GS_WINLEVEL: 
{ 
SetUpGame(); 
GameState=GS_STARTWAIT; 
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}break; 
case GS_LOSEGAME: 
{ 


GameState=GS_START; 
}break; 


} 


Prog_Loop doesnt really do much. It manipulates game state variables (mainly GameState), and calls func- 
tions depending on the value of Gamestate.T his use of a variable like GameState is pretty standard, but, 
of course, there are other, more efficient ways to implement it. For example, | could have created an array 
of pointers to functions that get called during each Prog_Loop.T his would certainly be more efficient 
than the switch | currently have in there, but since the code is instructional in nature (and because the use 
of function pointers would have been confusing to read), | used the switch. 


If you take a look at the const/ #define section of the code, you'll see that most of the stuff in there is 
hardcoded (such as the widths and heights of various objects). | have told you not to do this, and then | 
went and did it. Feel free to yell “hypocrite!” if you wish. Because of this choice! made, changing the code 
would be more difficult and prone to errors. Т he reason | hardcoded is because it speeded up develop- 
ment. (It is only an example, after all.) 


| want you to take a closer look at the code within the cs. PLAY game state: 


//limit frame time 

DWORD dwlimeStart=GetTickCount(); 
//move ball 

MoveBall(); 

//show board 

ShowBoard(); 

//show frame 
lpddsprime-»Flip(NULL,DDFLIP WAIT); 
//wait for 10 ms to elapse 
while(GetTickCount()-dwlimeStart<10); 


You'll notice the use of GetTickCount at either end of this game state Get TickCount retrieves the num- 
ber of milliseconds that have passed since you started your computer. As you enter this code, it sets 
dwTimeStart to the tick counter's current value. Later, the code spins a while until Get TickCount- 
dwTimeStart is no longer less than 10.Т his is called a frame rate lock. W ith this code, even on a super- 
fast machine made at some future date, this game will not output more than 100 frames per second (1000 
ms in a second, 10 seconds per frame). 
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IsoH ex9_ 1 is done, but not finished. W hat is the difference? W ell, when a game is “боле” it is playable. 
You can play this game for hours and hours, but it doesnt include the amenities that come with other 
games. Н егес a short list of features that 150Н ех9 1 needs in order to be "finished": 


= T he ability to set volumes and mute sounds 

= T itle screen 

= Top ten list 

= Some sort of messages when you start, die, or lose the game 
= M ауре some different types of levels 

= T he ability to play in a window 


As you can see, IsoH ex9_ 1 is far from finished. A lot of beginning game developers work on things like 
the title screen and other stuff before they work on the game itself. T his is not a good practice. O ften, 
you'll end up with 10 title screens and no games. | ve seen many a beginning game developer pour several 
days into making a really good title screen and main menu, only to later abandon the project. 


| left IsoH ex9_ 1 unfinished on purpose T he reason? | want you to finish it. T his game is by no means dif- 
ficult to finish. It just takes time and commitment. Finishing a game is a true accomplishment. If you dont 
want to finish this game, make a smallish game like it and finish that. Feel free to send me a copy. 


A Few WORDS AROUT 
FINISHING GAMES 


T he easiest thing in the world is to start a game project. T he hardest thing is finishing it. Since we as game 
developers are at heart game players, our attention span isnt as long as it could be. We start out working 
on a game, and we work on it for three days straight, and then we get burned out and say "I'll get back to 
it later" — but we never do. It just sits there, until eventually we reformat the hard drive, and then it's 

gone forever. | know | must have done this about a thousand times. W ith several hundred thousand game 
programmers out there, that means that there are several hundred million unfinished games out there. 
Several hundred million! 


№ eedless to say, you should finish a game you start. T his isnt as easy as it sounds. Boredom, burnout, 


a new game you pick up at the store— these are all things that keep us from finishing our games. D ont 
let them. 


A РЕЦ TiPS FOR FINISHING GAMES 


Following are just a few gems of wisdom I've acquired over the years. T hey make game development 
more likely to wind up with an actual finished product, rather than a collection of abandoned partially fin- 
ished games. 
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ТР #1: PACE YOURSELF 


Dont work 24 hours а day on anything. U nless you have a publisher, you don't have any deadlines, and 
you can take as long as you like making the game. Try not to work more than eight hours a day on it. If 
you have other commitments (job, school, family), dont work more than three to six hours a day. As a 
corollary, just a single hour, or even two hours, wont work. You have to get into “the zone” which takes 
about an hour to an hour and a half to achieve. 


Tir Fei PLAN, PLAN, PLAN 


Develop the games design before you start working on it. D raw everything, from main game play down to 
the menus. T he more you decide on during the design phase, the less you have to think about during 
development— you just have to take the concepts from paper to code. W rite down all your neat ideas. 
Also, if you decide to redesign part of the game while in the middle of development, step away from the 
computer to do the redesign. Avoid designing on-the-fly as much as possible. 


ТІР #5: KNOW YOUR LIMITATIONS 


Aim low. Yes, the sky's the limit, and you can do anything you put your mind to. W hatever. Aim low. By 
this, | mean that you should pick projects you know you can do. N ot think you can do. N ot something you 
migt be able to do. Something you cn do. Something you can do is more likely to be finished, as opposed 
to something where you first have to learn something. If you want to learn something, make a demo pro- 
gram that demonstrates how to use the new thing all by itself, not a game that uses it. 


Тір #Ч Шах ON, WAX OFF 


Even when you think youre finished, you could probably add some more polish. О п the other hand, there 
comes a time to declare things done. U sually, before you are finished with a project, you will hate working 
on it. T his is the trial by fire of all programs, especially those where you arent getting paid to make it. 
Push through that time, and finish. 


SUMMARY 


| cant possibly hope to imbue you with all the stuff about game design | ve absorbed over the years. M ost 
of it has become so ingrained in my programming style that | dont think about it— it just happens. It 
takes time to develop game design skills. It cant happen overnight, or even over the course of a book. 


T his closes the chapter and this part of the book. Н еге are a few thoughts | want to leave you with before 
moving on to the next chapter: 


« Design your game as fully as possible, and really think about the design. 

= Work incrementally. М ake small games as you start out and large ones later. 

= Finish your games. T he feeling of stepping back and looking at a finished piece of work is one of 
the best feelings in the world. 
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LAI ith this chapter, we break away from the introductory matter that filled Part 1 and start to move 
into the really cool stuff. N aturally, you arent going to fly when you havent walked yet. We will 
explore tile-based fundamentals, from both the management and user interface sides of the coin. 


WHAT Does “TILE-BASED"™ MEAN? 


You've seen floor tiles, right? Sometimes, especially in older buildings or in malls, different tiles are com- 
bined into a pattern (sometimes very elaborate patterns). T hat's exactly what we'll be doing, but instead of 
using linoleum or porcelain, well be using graphic images. 


T his is where the comparison ends between tile based games and floor tiles. W hen you make a tile based 
game, each graphic tile has a different meaning. О пе might be the floor, and the other solid rock (repre 
senting a wall). [п a tile based game, some sort of “characters” or "units" usually occupy tiles, and are 
moved around by either the player or the computer's Al. Т hese are called agnts in Al terminology. 


T he rules of the game determine what happens to the agents as they occupy the various tiles of the game, 
and they also govern how the agents may move from one tile to another. In a strategy game, an agent may 
be able to move three tiles per turn. Н owever, different tiles (such as grassland and hills) may have differ- 
ent "movement costs" associated with them. Grassland might only cost 1 to move, but a hill could easily 
cost 2 or 3. Further addition of things like roads or rivers may reduce these costs. It can all get very com- 
plicated very quickly. 


Of course, the player isnt really thinking about all this. H e just presses the up arrow to move to whatever 
square is there, and the computer takes care of movement cost. (Even though the player isnt consciously 
thinking about movement costs, he does know that it takes longer to traverse hills than it does to traverse 
plains.) 


Мутн= ABOUT TILe-BASED GAMES 


T he first myth about tile-based games is that they are dead. Т his is wholly untrue Yes, the days of pure 

2D tile-based games are over. Т hese days you have to have 3D rendering to make a really hot game. 

Н owever, even 3D games can be tile based, and many аге. T his is where isometric games come іп. | wont 
go into how isometric tiles work until chapter 11, but suffice it to say that isometric is 3D, even if it's done 
with just 2D rendering. M ost real-time strategy games and turn-based strategy games are made using iso- 
metric tiles (although the days of риге 2D isometric tile based games are drawing to a close as wall). 


T he second myth is that no one will buy a tile based game. Also untrue. [п your local computer game 
store, see for yourself. T he strategy genre is filled with tile-based games. 
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TILE-“BASED TERMINOLOGY 


W hile reading this section, keep in mind that these are mainly the terms | use You might have different 
names for them. For the most part, these terms are standard. 


= Tile A graphic used to render a portion of the background. W hen using rectangular tiles, this usually means 
that the entire rectangular area is taken up by the tile T his is not always so, however. You might have “fringe” 
tiles to take care of coastlines or a transition from one type of terrain to another, in which case the tile may 
cover only a portion of the rectangular area. 

" Sprite An arbitrarily-sized graphic that is usually used for either agents or foreground objects. Really, every- 
thing that isnt а tile is a sprite. Sprite is just a generic term, like tile You may decide to subclass them into 
units, buildings, and markers, depending on the type of game 

= T ileset. A set of tiles. It is inefficient to store each tile in a separate graphics file. It's easier to just take tiles 
and group them into logical sets and then place them all into a single graphics file that gets parsed later. A 
tileset might include sprites or might consist entirely of sprites. 

= Space Any arbitrarily-sized and shaped two-dimensional space. U sually a space is rectangular, but not in all 
cases. You tend to work with nonrectangular spaces using a bounding rectangle as well as whatever othe 
structure describes them. 

= Screen space Т he space on the screen used for rendering the play area, not including any borders, status pan- 
els, menu bars, message bars, or any other nonplay area structures. In some cases, the entire display is the 
screen space. О ften, it is not. 

» View space T he same size as screen space, but the upper-left corner is always at (0,0) for view space M any 
times, view space and screen space are the same. V iew space, in most cases, is purely abstract and plays no 
part in the rendering process. 

= Tile space T he smallest space (usually rectangular) that is taken up by an individual tile. In rectangular tiles, 
this is often the entire rectangle T ile space can also refer to the space taken up by a sprite. 

= World space T he space that allows the display of an entire map of tiles and their associated object/ agent 
sprites. In board games and puzzle games, world space may be equal to or smaller than screen space/ view 
space. In larger games, world space might be hundreds of times larger. Figure 10.1 shows the relationship 
between the screen, view, and world spaces. 
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Figure 10.1 


Screen, view, and 
world spaces and 
their relationship 


= Anchor. A correlation of one point of a space (usually (0,0)) to another space. An example of this is a cor- 
relation of view space to screen space If you had an 8-pixel border around the main viewing area, you would 
keep a point that kept track of the relationship from view space to screen space— namely, (8,8). T his lets you 
know how to convert between screen space and view space. Another example would be an anchor that con- 
verts from view space to world space. In a scrolling tile engine (with a world space larger than the view 
space), this anchor hdps determine which tiles have to be rendered by translating the tile’s world space coor- 
dinates into view space coordinates. From there, you can translate them into screen space coordinates. 

= Anchor space A space that defines legal values for the view-to-world anchor. Clipping your anchor point with 
anchor space lets you easily manage the view-to-world anchor and lets you keep the player from having an 
illegal view. 

= Extent. A rectangle relative to a point (usually an anchor), often with negative left and top values. W e will get 
into this more when | talk about using templates to manage files. 

= Tilemap. An array containing information about how the world looks— that is, which tiles аге in what loca- 
tion. T ilemaps also contain information about objects and agents in the world, even though the structure that 
contains agents or objects may be a different array, or not even an array at all. 

= Agent. Any sprite (or sequence of sprites used for animation) that moves, either by Al or by player action. 

= Object. An unmoving graphic, representing such things as trees, rocks, or other items. 


Н opel didnt lose you. If you're fuzzy on the real application of these terms, dont worry. I'll explore the 
meaning and uses of each as | go, and you will gain full understanding. 
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FAN INTRODUCTION TO 
RECTANGULAR TILES 
Rectangular tiles are the easiest of all to work with, because of their rectangular-ness. M ost of the time, 


when working in rectangle land, you use square tiles. You can use other sizes, of course, but square seems 
to be a favorite An example of a tile is shown in Figure 10.2. 


Figure 10.2 
A square tile 


T he point of view for games with square tiles is usually top 


down or overhead. T his just means that all your graphics must be NOTE I 
drawn as though you are looking down on the object. Т Ее жеке Қалы i іші 
Sometimes you сап give your game а slightly angled view so AIE SNT 
that you are looking mostly down, but you can see some of the Pin Set at aS 
front or back, depending on how the agent is facing. Н Е qe 
Another point of view for square tiles is the side scrolle view, straight at them. It gives the 
where you are looking at the world from its side Т his was very illusion of 3D without per- 
popular among older action games like Supe M ario Bros spective correction. Luckily, 
(N intendo) and the original D uke N uken. the human eye is easy to fool, 
because it automatically cor- 
W ith the advance of 3D display technology, both the top- rects for the errors in the 


down and side-scroller views have become nearly obsolete. projection. 


N ormally, you will want to group your tiles and sprites into 

graphical files where more than one tile or sprite is in the file 
N ormally, you'll want one or two files with the graphics for the background, a file for objects, and then a 
number of files for the agents (one file to an agent, unless you dont have too many animation sequences). 


T he examples shown in Figures 10.3, 10.4, and 10.5 are from Ari Feldman Spritel ib, which is a free 
graphics package that has been around for a few years. If you arent graphically inclined (dont be 
ashamed. .. you're not alone), you may want to download it from http:/ / www.arifeldman.com. 
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Figure 10.3 
Background tiles 
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MANAGING TILESETS 


T he tilesets and sprite sets you just saw are great, but they arent exactly in a form that is easy to work with 
for programmers like you and me. If you wanted to work with them, you'd have to store a bunch of rec- 
tangles in а text file or other configuration file, or (ap!) you'd have to hardcode image rectangles. Later, if 
you decided to change the art, this would be a maintenance horror show. You'd have to go back and change 
around the rectangle lists. O f course you'd forget one, and naturally you wouldnt find out until one of 
your beta testers got really far into the game. .. well, | think you get the idea. 


So, what's the solution to this dilemma? Templates. A template is used in the first example of a tileset— the 
one with the white boxes around it (Figure 10.3). T hat's one way to do a template. Н owever, it's not the 
best way, because you still have to either hardcode or put into a configuration file the width and height of 
the template. 


Load 150Н ех10 1.bmp into your favorite graphics editing program. Figure 10.6 shows what it looks like 


Figure 10.6 


A sample tileset 


You can see the border around each of the images. U nlike the tileset shown in Figure 10.3, the border is 
green instead of white. О г is it? 
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Take а really close look at the top cell (zoom in as far as the program will let you), shown in Figure 10.7. 


Figure 10.7 


Zooming in on the caveman 


T here is more than just green. .. there is also white and cyan (you cant see it too well in the book, but you 
can see it just fine in a graphics program). As you might have guessed, each of the different colors means 
something. T he green dots span the width and height of the image W hite dots are part of the frame but 
outside of the image. T he black dot in the corner is what designates the corner of a tile cell, and also the 
transparent color of the tileset.T he cyan dot (or blue dot) designates a coordinate for the tiles anchor. (| 
use cyan when the anchor is within the bounds of the tile image itself. In other words, it would otherwise 
be a green dot, and blue when the anchor point would otherwise be white) 


W hy these colors? W hy not a completely different set of colors? Quite frankly, you could use а different set 


of colors, and this type of template supports just that. Take a look and zoom in on the upper-right corner 
of the tileset (shown in Figure 10.8). 
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Figure 10.8 


The upper-right corner of the tileset, 
demonstrating control colors 


T here are five pixels in the rightmost column, in the following order: black, white, blue, green, and cyan. 

T hese specify corner, frame, anchor, inside, and inside anchor, respectively. If you wanted to, you could 
change one of these colors to red (for example), and put it in the proper control color position, and use it 
instead of the color used here. 


U sing an extended template like this gives you a great deal of freedom. You can make a template and later 
change the width or height of the cells, and it will still load the same way. T he green and blue and cyan 
pixels let you calculate tile spaces, anchor points, and tile extents, which you can parse into arrays of rec- 
tangles and points. You can move an image's anchor point and have it show up in a different location. An 
extended template takes pressure off programmers and removes stress from artists, who, when using it, are 
less constrained by the normally tight restrictions for tile-based graphics. 


Before you finish building your utopian society, though, you have to write code that will parse a graphics 
file into arrays of rectangles and points. і «5 start by figuring out what information you need about each 
tile. Presumably, these templated graphics will be on an 1DirectDrawSurface7 Somewhere, and you want 
to optimize your data structures for using 81% and 81tFast. Since both of these use source rectangles, 
you'll definitely want to keep an array of кЕСТ5 for that. T he coordinates held in these necs will be pixel 
coordinates measured from (0,0) in the tileset's image. Figure 10.9 shows what one of these вЕСТ5 might 
look like. 
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Figure 10.9 
Source RECT 


In Figure 10.9, the rect has the coordinates ( 1,1)- (39,6 1). Remember that you have to add one to the 
bottom and right because of how кестѕ work. Doing so gives you a resulting Rect of (1,1)- (40,62). 


Because you might or might not be referencing off the upper-left of these source вестѕ (the blue and cyan 
points might lie elsewhere), you need an array of ротмтѕ to keep track of the tile anchors. Like the source 
rectangles, these POINTS contain coordinates into the tileset image, meaning that a tile with a rectangle of 
(100,100)- (200,200) has its anchor point within the x and y range of that вест (rather than having the 
anchor point in reference to the tile cell's upper-left corner, which is another way you could have done this 
that would have added unnecessary computations). Figure 10.10 shows the anchor point. 


Figure 10.10 


Anchor point 


TILE-BASED FUNDAMENTALS 


In Figure 10.10, the anchor point is (7,1), which is within the range of your source RECT, as | said it 
would be. 


Finally, you add another array of вЕСТ$ to hold the tile extents. Extents can be calculated after the source 
RECT and anchor ротмт have been determined, like so: 


//copy source rect 

CopyRect(&rcExtent,&rcSrc); 

//offset by anchor point 
OffsetRect(&rcExtent,-ptAnchor.x,-ptAnchor.y); 


In this case, the extent is (- 6,0)- (32,60). T he derivation of these values is as follows: 
U pper L eft: 
From source RECT (1,1) 
Minus anchor point (7,1) 
Combine coordinates (1-7,1-1) 
Solve (-6,0) 


Bottom Right: 

From source RECT (40,62) 
Minus anchor point (7,1) 
Combine (40-1,62-1) 
Solve (33,61) 


Yes, there's a negative left coordinate; this is quite common for this type of tileset, where you might want 
to reference a tile from a point other than the upper left. It would not be a stretch to use the character's 
feet or center. Just use whatever works to give an animation continuity and smoothness. For this tileset, the 
horizontal aspect of the anchor lines up with the back of the сауетап5 hair. 


T he idea here is that you want to be able to simply specify a single (x,y) screen coordinate and tall it which 
tile to blit, and have it come out right. W hen blitting, the (x,y) point corresponds to the tiles anchor 
point. T his means that if you tell this tile to blit to screen coordinate (100,100), you want screen coordi- 
nate (100,100) to correspond to the tileset image's coordinate (7,1). 


You want the extent so that you can simplify the process of determining the coordinates of the destination 
ВЕСТ (or the destination (x,y) for B1tFast). Taking the source кест and subtracting the point gives you 
the extent. Т his way, based on a single set of coordinates (dstx and dst v), you can determine the proper 
destination rectangle. For example: 
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//for Bit 
CopyRect(&rcDst,&rcExtent) ; 
OffsetRect(&rcDst,dstX,dstY); 
//perform the Blt 


//for BltFast 
dstXt=rcDst. left; 
dstYt=rcDst.top; 
//perform bltfast 


If you didnt precalculate the extents, you would have to calculate them from the source rectangle, anchor 
point, and destination point each time you wanted to render the tile Although doing so isnt too much 
more work (about a dozen add or subtract operations), it is work, and in game programming, you want to 
avoid any work that you can. Precalculating tile extents might give you just one extra frame per second or 
even only half а frame per second, which doesnt’ sound like much, but if you have two optimizations that 
each give you an extra half-frame per second, youve just earned yourself another frame per second. Game 
programming is a game of inches. 


Al TILES€ET CLASS 


So, now that you've decided what information you want, you just have to go in and get it. | made a class to 
work with these sorts of templates. It's called cTi1eSet, and you can find the code for it in T ileSet.h and 
T ileSet.cpp. 


THE CLASS DECLARATION 


First, | designed a struct to contain important information about tiles, including source rectangle, anchor 
point, and destination extent. | put this information into TILEINFO. 


//tileset information structure 

struct TILEINFO 

{ 
ВЕСТ rcSrc;//source rectangle 
POINT ptAnchor;//anchoring point 
RECT rcDstExt;//destination extent 
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T he members of TILEINFO are explained in Table 10.1. 


Table 10.1 TILEINFO Members 
TILEINFO Member Meaning 


reSrc Source RECT for the tile 
ptAnchor Anchor POINT for the tile 
rcDstExt Destination extent RECT for the tile 


N ext, heres the class itself: 


class CTileSet 

{ 

private: 
//number of tiles in tileset 
DWORD dwTileCount; 
//tile array 
TILEINFO* ptiTileList; 
//filename from which to reload 
LPSTR lpszReload; 
//offscreen plain directdrawsurface/ 
LPDIRECTDRAWSURFACE7 lpddsTileSet; 


public: 


//constructor 
CTileSet(); 
//destructor 
~CTileSet(); 

//Тоаа (initializer) 

void Load(LPDIRECTDRAW/ lpdd,LPSTR lpszLoad); 
//reload (restore) 

void Reload(); 

//unload (uninitializer) 

void Unload(); 

//get number of tiles 

DWORD GetTileCount(); 

//get tile list 


225 


250) ISOMETRIC GAME PROGRAMMING WITH, DIRECTX 7,0 


TILEINFO* GetTileList(); 

//get surface 

LPDIRECTDRAWSURFACE7 GetDDS(); 

//retrieve filename 

LPSTR GetFileName(); 

//blit a tile 

void PutTile(LPDIRECTDRAWSURFACE7 lpddsDst,int xDst,int yDst,int 
iTileNum); 
bs 


T he private members contain all of the information needed to process the tileset. T hese are listed in 
Table 10.2. 


Table 10.2 CTileSet Private Members 
CTileSet Private Member Meaning 


dwTileCount The number of tiles contained in the tileset 

ptiTilelist A pointer to an array of TILEINFO that describes each tile 
lpszReload The file name from which this tileset was loaded 
lpddsTileSet The IDirectDrawSurface7 pointer that is the off-screen 


surface containing the tileset 


T he member functions in the public section perform all necessary operations on the tileset. Table 10.3 
explains these member functions. 
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Table 10.3 CTileSet Public Member Functions 
CTileSet Public Member Function Purpose 


CTileSet Constructor that initializes all variables to 0 
Or NULL 

~CTileSet Destructor that calls Unioad 

Load Loads and parses an image 

Reload Reloads the image (if for some reason the sur- 
face has been freed, such as resulting from an 
Alt+Tab) 

Unload Frees the resources associated with the tileset 

GetTileCount Returns the number of tiles 

GetTileList Returns the tile info pointer 

GetDDS Returns a pointer to the 
IDirectDrawSurface7 containing the tileset 

GetFileName Returns the name of the file from which the 
tileset was loaded 

PutTile Puts a tile on a surface, given a coordinate and 
a tile number 


T he constructor and destructor dont do much and arent very interesting, but the other functions are more 
important, so l'Il explain them in more detail. 


CTILES€ETEELOAD 

T his function loads a bitmap and places it onto а D irectD raw surface and also parses the image into its 
component tiles. 

void CTileSet::Load(LPDIRECTDRAW/ lpdd,LPSTR IpszLoad); 


T he ipdd parameter is a pointer to an 1DirectDraw object, which is used to initially create the tileset 
surface T he 1pszLoad parameter is the name of the file to load that contains the image you want for 
this tileset. 
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T his function is quite long, because of the image parsing. It performs the following tasks: 


1. Loads the image. 

Grabs the control colors from the upper-right corner. 

Counts and measures the horizontal and vertical cells. 

Allocates the tile list. 

Scans each tiles left and top for anchor points and inside points (using default values if these 
control points are not specified). 

6. Calculates destination tile extents. 


All of the main work is done here, at load time, so that after a call to Load, you can immediately start 
using PutTile, and you never really have to worry about it ever again. 
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CTILESETIARELOAD 


CtileSet::Reload reloads an image if and when it is lost due to a display mode change or Alt+T ab 
incident. 


void CTileSet::Reload(); 


If, as a result of an Alt+Tab or other such misfortune, your tileset's surface is lost, a call to 
IDirectDraw7::RestoreAllSurfaces may be required. After that, you can call cTileSet: :Reload, and 
the image will be reloaded (but not reparsed). 


CTiLEBETRRSLUINLORD 


T his frees all the resources used by the tileset. It is called during the destructor and whenever Load is 
called. 


void CTileSet::Unload(); 


Very likely, you will never call this function directly, since it is taken care of in the destructor. Even if you 
wanted to load a different image into a tileset, you could just call Loaa. T he only time you would ever 
want to call Unload is № you were trying to conserve video memory for other images. It is here mainly for 
completeness. 


CTILESETEGETTILECOUNT 
T his ones а no-brainer. 

DWORD CTileSet::GetTileCount(); 

T his function returns the number of tiles in the set. 
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СТЕБ ЕТЕ Е СЕТТІ кілет 


T his function gives you access to the tile information, which is very important if you want to implement 
dipping yourself rather than relying on a D irectD raw clipper and cTileSet::PutTile. 


TILEINFO* CTileSet::GetTileList(); 


T his function returns the pointer to the tile array. You can use the result of this function just as you would 
an array. 


//make tileset 

CTileSet tsExample; 
tsExample.Load(lpdd,"Sample.bmp") ; 
//retrieve the info about tile zero 
TILEINFO ti=txExample.GetTileList()[0]; 


СТЕБ ЕТЕЕ СС ЕТОО 5 
T his function allows access to the D irectD raw surface on which dwell the tiles. 
LPDIRECTDRAWSURFACE7 CTileSet::GetDDS(); 


T his function returns the 1DirectDrawSurface7 pointer that contains the image of the tileset. If for 
some reason you wanted to modify or read from the surface, this would be the function youd start with. 
Keep in mind that any changes you make to the surface will not survive a call to CTi1eSet: :Re10ad. Also, 
if you want to keep a copy of the surface pointer for a long time, it might be best to use AddRef so that 
the surface isnt inadvertently deleted in the interim. 


СТЕ бета в СЕТЕ Е Мяг 

T his function is pretty self-explanatory. 

LPSTR CTileSet::GetFileName(); 

T his returns a pointer to the file name that is used to reload the tileset. 


СТЕБ ЕТЕЕ Р ОТТЕ 
T his function is the reason for the whole show. It's the workhorse of the cri1eset Class. 


void CTileSet::PutTile(LPDIRECTDRAWSURFACE7 lpddsDst,int xDst,int yDst,int 
iTileNum) ; 


T his takes care of putting a tile onto a destination surface (1 pddsDst), With xDst, yDst corresponding to 
the anchor point of the specified tile (4 Ti 1eNum). Т iles are numbered starting with 0 and are ordered left 
to right, top to bottom. 
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AN ANIMATED SPRITE EXAMPLE 


O ne of the many uses for а tileset is for an animated sprite sequence. Earlier in this chapter, | showed you 
a tileset consisting of some caveman images from spriteib, which is а good example of one such animation 
sequence. Load up 150Н ех10 1.cpp, which makes use of стітеѕе+ (among other things; see the top of 
IsoH ех10 1.срр). If you load and run it, you will see the caveman running in place, as shown in Figure 
10.11. 


Figure 10.11 


Animation demo 


T his example is based on IsoH ex1 1.срр, just like the rest of the examples. T he main differences exist in 
Prog_Init, Prog_Loop, and Prog_Done 


SETTING UF 


T he Prog Init does the required D irectD raw setup (creating the D irectD raw interface, creating the pri- 
mary surface and the back buffer). It also loads the tileset into tsCaveMan (а global cTileSet variable). 


bool Prog_Init() 
{ 

//create IDirectDraw7 

lpdd-LPDD Create(hWndMain,DDSCL FULLSCREEN | DDSCL EXCLUSIVE | 
DDSCL ALLOWREBOOT) ; 

//set display mode 

lpdd->SetDisplayMode(800,600,16,0,0); 
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//create primary surface 
pddsMain-LPDDS CreatePrimary(lpdd,1); 
/get back buffer 
pddsBack-LPDDS GetSecondary(lpddsMain); 
/clear out back buffer 
DBLTFX ddbltfx; 

DBLTFX ColorFill(&ddbltfx,0); 
lpddsBack-»Blt(NULL,NULL,NULL,DDBLT WAIT | DDBLT. COLORFILL,&ddbltfx); 
//Тоаа in tileset 

tsCaveMan.Load(lpdd,"IsoHex10 l.bmp"); 

return(true);//return success 


D CJ — — ы — 


THE MAIN LOOF 


In Prog_Loop, three things happen. First, the back buffer is cleared out. Second, one of the cells of the 
tileset is written to the approximate middle of the screen. T hird, the application is locked to 15 frames per 
second. 


void Prog_Loop() 
{ 


//start timer 

DWORD dwlimeStart=GetTickCount(); 
//clear out back buffer 

DDBLTFX ddbltfx; 
DDBLTFX ColorFill(&ddbltfx,0); 
lpddsBack-»Blt(NULL,NULL,NULL,DDBLT WAIT | DDBLT COLORFILL,&ddbltfx); 
//put the caveman 
tsCaveMan.PutTile(lpddsBack,400,300,dwCaveManFrame) ; 
//change the frame number 

dwCaveManFrame++; 
dwCaveManFrame2-8; 
//flip 
lpddsMain->Flip(NULL,DDFLIP_WAIT); 
//lock to 15 FPS 
while(GetTickCount()-dwlimeStart<66) ; 
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You can see that using cTileSet is a great deal easier than setting up RECTS and going down that path. 
T he tileset makes sprite and tile management easy and doesnt add that much overhead. 


CLEANING UF 


You don't have to call the un1oad function, because ст11езет 5 destructor automatically does so, and you 
can essentially ignore your tileset in Prog_Done. You can just destroy the primary surface and the 
IDirectDraw and be done with it. 


void Prog Done() 

{ 
//destroy primary surface 
LPDDS_Release(&lpddsMain) ; 
//destroy IDirectDraw7 
LPDD_Release(&lpdd); 


TAKING CONTROL 


Although just watching a caveman run in place is fun, you'd probably rather control him. For this, | wrote 
IsoH ex10_2.cpp.T his example is mostly the same as 150Н ex10 1, except that now you respond to the 
arrow keys and use that information to move the caveman back and forth across the screen. T he major 
change happens in Prog_Loop. 


void Prog_Loop() 
{ 
//start timer 
DWORD dwTimeStarteGetTickCount(); 
//clear out back buffer 
DDBLTFX ddbltfx; 
DDBLTFX ColorFill(&ddbltfx,0); 
lpddsBack-»Blt(NULL,NULL,NULL,DDBLT WAIT | DDBLT COLORFILL,&ddbltfx); 
//put tile 


tsCaveMan[dwCaveManFace].PutTile(lpddsBack,dwCaveManPosition,300,dwCaveManFrame) ; 
/ /move 
if (MoveLeft*MoveRight) 
{ 
if (MoveLeft) 
{ 
//moving left 
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dwCaveManFace=1; 
//update position 
dwCaveManPositiont+=796; 
dwCaveManPositionz-800; 
//update animation frame 
dwCaveManFramet=1; 
dwCaveManFrame2-7; 


else 


//moving right 
dwCaveManFace=0; 
//update position 
dwCaveManPositiont-4; 
dwCaveManPositionz-800; 
//update animation frame 
dwCaveManFramet=1; 
dwCaveManFrame2-7; 


//standing 

dwCaveManFrame=/ ; 
} 
//flip 
lpddsMain-5»Flip(NULL,DDFLIP. WAIT); 
//lock to 15 FPS 
while(CGetTickCount()-dwTimeStart«66); 


T he global variables named MoveLeft and MoveRight are 00015, and you change their status in response to 
WM. KEYUP and WM_KEYDOWN. 


case WM KEYDOWN: 
{ 
//on escape, destroy main window 
if (wParam==VK_ESCAPE) 
{ 
DestroyWindow(hWndMain); 


} 


//movement keys 
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if (wParam==VK_LEFT) 
{ 
MoveLeft=true; 


} 
if(wParam--VK RIGHT) 
{ 
MoveRight=true; 
} 
return(0);//handled 
}break; 
case WM_KEYUP: 
{ 
//movement keys 
if (wParam==VK_LEFT) 
{ 
MoveLeft=false; 
} 
if(wParam--VK RIGHT) 
{ 
MoveRight=false; 
} 
return(0);//handled 
}break; 


ІП Prog. Loop, you can see that, depending on which key is 
being pressed, the facing (contained in dwCaveManFace), the 
position (dwCaveManPosition), and the animation frame 
(dwCaveManFrame) are updated. N othing happens if both 
keys are pressed at the same time. 


T his is about it for your crash course in tile and sprite man- 
agement. T hroughout the rest of the book, you will make 
heavy use of cri1eset. | hopel've shown you that this stuff 
isnt so hard after all, as long as you have the proper tools and 
classes to help you. 


NOTE 


You may have noticed that no 
subtraction is done—only addi- 
tion. This is because all the vari- 
ables are DWORDs, or unsigned 


longs, which have no negative 
values. You can see that all the 
additions are shortly followed by 
a modulus (?9 operation. 
Combining addition and modu- 
lus, you get a net subtraction. 
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TILEMAP BASICS 


A singletile, or even a sequence of tiles depicting an animated character, isn't in itself very useful. In order 
to be useful, a variety of sprites and tiles must be used together. N ow that you've seen how easy it is to 
manipulate tilesets, the time has come to get into tilemaps. W hen creating a tile based world, you must 
have а way to represent it in your computer's memory. U sually, you do so with some sort of array, 
although there are other more complicated but more flexible solutions. 


Since we are still in rectangle land, our tilemaps are more intuitive than they will be once we get into iso- 
metric and hexagonal tilemaps. T hey are simply two-dimensional arrays, like so: 


int iTileMapLWIDTH][HEIGHT]: 


WIDTH and HEIGHT can be any old value— whatever you need to make your tilemap the proper size. In a 
chess or checkers game, WIDTH and HEIGHT would both have a value of 8. A side-scroller might have а 
HEIGHT equal to the screen height divided by thetile height, but the width of the map times the width of 
the tiles might be several times the width of the screen. T he WIDTH and HEIGHT values depend entirely on 
what kind of game you are making. 


T he meaning of the numbers in this array remains in question. Intrinsically, they have попе; the meaning 
of the numbers is entirely up to you. You may not even have ints in the array, but instead a completely dif- 
ferent custom structure. A gain, this is entirely game-dependent. 


For example, in a checkers game, the board squares are alternately black and red, as shown in Figure 10.12. 
You might put this in the number as a bit flag (if bit 0 is set or not set, for example). On the other hand, 

you might decide that a board whose x and y add up to bean even number is black, and an odd number is 
red, like so: 


if((tilext+tiley)&l) 
{ 


//red square 


//black square 
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Figure 10.12 
A checkerboard 


Figure 10.13 shows the calculations for (x+y) & 1 for the sample checkerboard. 


Figure 10.13 


Alternating 
odd/even 
checkerboard 
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You may want to only contain in your checkerboard's tile array which piece is or is not there. T here area 
total of five options: black piece, red piece, black king, red king, and empty; you might create an enum to 
keep track of them. 


enum{ EMPTY=0, BLACKPIECE=1, REDPIECE=-1, BLACKKING=2, REDKING=-2}; 


In this scheme, all black pieces are positive numbers, and all red pieces are negative. Т his provides an easy 
way to differentiate them and conveniently leaves 0 for representing empty. T he starting board configura- 
tion tilenap values are shown in Figure 10.14. 


Figure 10.14 


Starting board 
configuration 


MORE COMPLICATED TILEMAFPS 


Checkers is a good example of a game for which to use a very simple map structure. T here isnt much vari- 
ety in the tiles this map can hold. T his is true of most board and puzzle games, like chess, Reversi, and so 
on. H owever, more complicated games like turn-based or real-time strategy games are more visually rich 
and thus have a more complicated map structure. Also, these types of maps tend to be layered. 


For example, you might decide that your turn-based strategy game will have several different types of ter- 
rain: ocean, plains, forest, hills, and mountains. T hese would become your basic terrain types. In addition, 
you might want to have rivers and roads connecting various map squares. Roads and rivers would be con- 
tained in different layers. Also, you'll undoubtedly want to have cities and units on the map, and this сап 
add even more layers. To accomplish all this layering, you might have a struct like the following to describe 
your Шетар areas: 
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struct TILEMAPSQUARE 
{ 


char BasicTerrain;//0=ocean;1l=plains;2=forest;3=hills;4=mountains; 
unsigned char RoadFlags;//bit O=north; bit l=northeast; bit 2=east; etc. 
unsigned char RiverFlags;//bit O=north;bit l=east;bit2=south;bit3=west 
UNIT* Unit;//pointer to a unit 

pS 


| think you get the idea. T he more rich the world, the more complicated becomes the map structure. For 
now, we will stick with simplistic tilemaps. We'll get into more complicated structures in later chapters. 


RENDERING A TILEMAP 


Storing a tilenap somewhere in an array is important. D oing so allows you to persist a world without hav- 
ing to hardcode it. W ith such a tilemap, you can save to and load from disk, and create an editor that 
allows you to modify the map. Creating an editor is a great idea; you can distribute it with your game so 
that your players can create their own levels if they wish, thus enhancing the replay value of your game. 
Таке for example, the popularity of Civilization 11, which was written several years ago but is still played 
heavily. Entire W eb sites are dedicated to modified tilesets and scenarios that can be played within the 
game. 


Н aving said that, let's talk about how to render a Шетар, and then we'll make a simple map editor 
that uses а tileset from spritelib. ІЛІ bring up and talk about some of the terms | mentioned earlier in 
this chapter. 


SCREEN SPACE 


First, we'll talk about screen space in more depth. Screen space is nothing more than a rectangle describing 
the play area shown on-screen. T his could be the entire screen, or it could be a smaller portion. M ost 
modern games have some sort of status bar on the side or bottom of the screen, so quite often screen 
space is smaller than the entire screen. 


For the editor that we will be making, let's use 800х600х16 mode. W e will use a 600x600 area for edit- 
ing the map on the left side of the screen, leaving 200x600 on the right for tile selection. T he tiles we will 
be using are 32x32. T he tileset is shown in Figure 10.15. 
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Figure 10.15 


Tileset for the editor 


Of course, neither 200 nor 600 is evenly divisible by 32. 200/ 3226.25, and 600/ 32= 18.75, leaving 
extra pixels. For this reason, there will be borders around both the editing panel and the tile selection 
panel, as shown in Figure 10.16. T his makes the map panel 576х576 (or 18 tiles by 18 tiles), and the tile 
selection panel 192x576 (or 6 tiles by 18 tiles). 


Figure 10.16 


Layout of the map 
editor 


Tile 
Panel 
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You want your map panel centered within the 600x600 rectangle, and you want the tile selection panel 
centered within the 200x600 rectangle on the right. T his will give your map panel вест the value of 
(12,12)- (588,588) and your tile selection rect the value of (12,604)- (796,588). T his gives you not one, 
but two screen spaces. [п the map panel, draw the current representation of the map based on your map 
array, which contains indices into the tileset (make the Шетар 18x18 so that it conveniently fits). [п the 
tile selection panel, draw all the tiles, in order, and outline the one that is currently selected. 


But now you have more tiles in the set than will fit in the tile selection box. You can fit 6x18 tiles (108 
tiles), but you have 192. In order for the editor to be any good, you must either reduce the number of tiles 
in the se— something you dont want to do— ог make it so that all the tiles can be selected by allowing 
some sort of scrolling mechanism. T his is a better solution. You may, at some point, want to handle a vari- 
ably-sized tileset, so not locking yourself into a fixed-size tileset is wise. 


WORLD SPACE AND VIEW SPACE 
You have already decided to have an 18x18 tile grid, and this will be the total of your world space. Since 


each tile is 32*32, this makes the pixel measurement of world space 576х576. Since you are making world 
space 0-based, the world space вест is (0,0)- (576,576). 


Your view space is based on your screen space. Since screen space spans from (12,12)- (588,588), you 
simply must subtract (12,12) from each coordinate pair to determine your view space Т his makes view 
space 0-based, which makes conversion from one space to another much easier. T he point (12,12) is called 
the screen-to-view anchor. 

U pper Left: 

Screen coordinate ( 12,12) 

M inus anchor (12,12) 

Combine (12- 12,12- 12) 

Solve (0,0) 


Lower Right: 
Screen coordinate (588,588) 
M inus anchor (12,12) 
Combine (588- 12,588- 12) 
Solve (576,576) 
Conveniently, your view space RECT works out to be (0,0)- (576,576), which is exactly the same as your 


world space RECT, meaning that no conversion is necessary to go from world to view space. So, to convert 
from world to screen space, simply add the coordinate ( 12,12). To do the reverse, subtract (12,12). 
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A SIMPLE TILEMAP EDITOR 


Load up 150Н ex10_3.cpp. T his example demonstrates what weve been talking about for the last several 
pages. It sets up а map pane and а Ше panel. T he map pane is your screen space for the tilemap. T he tile 
panel shows the variety of tiles that you can place in the tilemap. Figure 10.17 shows sample output for 
this example. 


Figure 10.17 


A simple Ti 7eMap 
MÀ. editor 


T he controls for this example are rather simple, and the features rather slim. Clicking anywhere in the map 
panel puts the selected tile there. Clicking in the tile panel selects a new tile. Clicking above or below the 
tile panel scrolls the tile panel up or down. All in all, this example is pretty spartan. It doesnt save, it does- 
nt load, it doesnt really do much except let you play with the tileset. Still, | think it's a pretty good exam- 
ple of what a етар editor looks like at its very core. L ets take a look at how it works. 


CONSTANTS 


First, | made a number of constants to keep track of the sizes in the editor. Quite a few of them are 
dependent on other constants. 


//map and tile constants 
const int TILEWIDTH=32; 
const int TILEHEIGHT=32; 
const int MAPWIDTH=18; 
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const int MAPHEIGHT=18; 

//panels 

const int MAPPANELX=12; 

const int MAPPANELY=12; 

const int MAPPANELWIDTH=MAPWIDTH*TILEWIDTH; 

const int MAPPANELHEIGHT=MAPHEIGHT*TILEHEIGHT; 
const int TILEPANELX=604; 

const int TILEPANELY=12; 

const int TILEPANELCOLUMNS=6; 

const int TILEPANELROWS=18; 

const int TILEPANELWIDTH=TILEPANELCOLUMNS*TILEWIDTH; 
const int TILEPANELHEIGHT=TILEPANELROWS*TILEHEIGHT ; 
GLOSALS 


Besides our usual globals (window handle, our D irectD raw pointer, and our primary and back surfaces), 
there are a few extras with which to keep track of the state of the editor. 


//tileset 

CTileSet tsTileSet; 

//tilemap 

int iTileMapL MAPWIDTH]LMAPHEIGHT]; 
//tile selection 

int iTileTop=0; 

int iTileSelected=0; 


T he tsri eset variable contains the tileset you'll be using. i ri 1eMap is the array in which you contain 
your етар. T he itileTop and iTileSelected variables are for managing the tile selection panel. 
iTileSelected keeps track of what tile is currently selected for drawing, and iTi 1eTop tracks what tile is 
shown at the top of thetile selection pand. 


SET UP AND CLEAN UP 

Т he changes to Prog Init are minor. You set up DirectD raw, load your tileset, and clear out your етар. 
| wont list the function's contents here. In Prog. Done, there are effectively no changes, since you neither 
have to deallocate the tilemap nor destroy the tileset. 
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THE MAIN LOOF 


T he main loop itself (Prog Loop) does virtually nothing. It delegates to ShowMapPane1 and 
ShowTilePanel and then performs а flip. 


SHOWMAPPANEL 


T his function has no parameters, returns no value, and carries out two tasks. Т he first task is clearing out 
the entire map panel with black. T he second is looping through all the tiles in the tilemap and putting 
them onto the map pand. 


void ShowMapPanel() 
{ 
//clear out map panel 
//set up fill rect 
ВЕСТ rcFill; 
SetRect(&rcFill,MAPPANELX,MAPPANELY ,MAPPANELX+MAPPANELWIDTH,MAPPANELY+MAP - 
PANELHEIGHT); 
//set up ddbltfx 
DDBLTFX ddbltfx; 
DDBLTFX ColorFill(&ddbltfx,0); 
lpddsBack-»Blt(&rcFill,NULL,NULL,DDBLT WAIT | DDBLT COLORFILL,&ddbltfx); 
//loop through map 
for(int mapy=0;mapy<MAPHEIGHT ;mapy++) 
{ 


for(int mapx=0;mapx<MAPWIDTH;mapx++) 
{ 


//put the tile 
tsTileSet.PutTile(lpddsBack,MAPPANELX+mapx*TILEWIDTH, 
MAPPANELY+mapy*TILEHEIGHT,iTileMap[mapx][mapy]); 
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SHOWTILEPANEL 


ShowTilePanel is responsible for displaying all of the tiles in the tile panel and for placing a white box 
around the currently selected tile 


void ShowTilePanel() 
{ 


//clear out map panel 

//set up fill rect 

RECT rcFill; 

SetRect(&rcFill,TILEPANELX, 
TILEPANELY,TILEPANELX- 
TILEPANELWIDTH, TILEPANELY+ 
TILEPANELHEIGHT) ; 
//set up ddbltfx 
DDBLTFX ddbltfx; 
DDBLTFX ColorFill(&ddbltfx,0); 
lpddsBack-»Blt(&rcFill,NULL,NULL, 
DDBLT WAIT | DDBLT. COLORFILL,&ddbltfx); 

//set tile counter to first tile 

int tilenum-iTileTop; 

//loop through columns and rows 

for(int tiley=0;tiley<TILEPANELROWS; ti ley++) 

{ 


— 


for(int tilex=0;tilex<TILEPANELCOLUMNS ;tilex++) 

{ 
//check for tilenum’s existence in tileset 
if(tilenum<tsTileSet.GetTileCount()) 
{ 


tsTileSet.PutTile(lpddsBack, TILEPANELX+tilex*TILEWIDTH, TILEPANELY+ti ley*TILE- 
HEIGHT ,tilenum) ; 
//check for selected tile 
if(tilenum--iTileSelected) 
{ 
//grab the dc 
HDC hdc; 
lpddsBack->GetDC(&hdc) ; 
//calculate outline rect 
RECT rcOutline; 
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t(&rcOutline, TILEPANELX+ 
x*TILEWIDTH, 
PANELY+ 
y*TILEHEIGHT, 
PANELX+ 
TILEWIDTH+ 
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(HPEN)GetStockObject(WHITE_PEN) ); 


MoveToEx(hdc,rcOutline.left, 
rcOutline.top,NULL); 


LineTo(hdc, 
LineTo(hdc, 


1s 


LineTo(hdc, 
LineTo(hdc, 


rcOutline 
rcOutline 


rcOutline 
rcOutline 


//release the dc 
lpddsBack-»ReleaseDC(hdc); 


} 
//increase tile counter 
tilenum++; 


ACCEPTING INPUT 


//select a white pen into dc 
SelectObject(hdc, 


//place selection rectangle 


.right-1,rcOutline.top); 
-right-1,rcOutline.bottom- 


.left,rcOutline.bottom-1); 
.left,rcOutline.top); 


T he only topic left to cover is accepting input and making things happen. I'm only going to show the 
event handler for им_гвиттомоомм, since the handler of wM_MOUSEMOVE is almost identical, and because of 


the sheer size of the handler. 


In essence, the wM_LBUTTONDOWN handler takes the position of the mouse and places it in a POINT variable 
called ptMouse.T hen it sets up a series of кестѕ— one for the map рапе, one for the tile panel, one for 
the area above the tile panel, and опе for the area below the tile panel. It checks to see if the mouse is 
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within these бест, and if it is, it carries out the appropriate action: place а tile if within the map pand, 
select a tile if within the tile pand, scroll the tile panel up if above or down if below. 


WM MOUSEMOVE does mostly the same thing, except for the scrolling of the tile pane if above or below. 


case WM_LBUTTONDOWN: 
{ 


//point to contain mouse coords 
POINT ptMouse; 
ptMouse.x=LOWORD(1Param) ; 
ptMouse.y=HIWORD(1Param) ; 
//RECT used for zone checking 
RECT rcZone; 

//other variables 

int mapx=0; 


int mapy=0; 
int tilex=0; 
int tiley=0; 


int tilenum=0; 
//check the map panel 
SetRect(&rcZone,MAPPANELX,MAPPANELY, 
MAPPANELX+MAPPANELWIDTH, 
MAPPANELY+MAPPANELHEIGHT) ; 
if(PtInRect(&rcZone,ptMouse)) 
{ 


//in map panel 

//calculate what tile mouse is on 
mapx=(ptMouse.x-MAPPANELX)/TILEWIDTH; 
mapy=(ptMouse.y-MAPPANELY )/TILEHEIGHT; 
//change map tile to currently selected tile 
iTileMap[mapx][mapy ]J=iTileSelected; 
return(0);//handled 


} 

//check the tile panel 

SetRect(&rcZone, TILEPANELX, TILEPANELY, 
TILEPANELX+TILEPANELWIDTH, 
TILEPANELY+TILEPANELHEIGHT) ; 

if(PtInRect(&rcZone,ptMouse)) 

{ 


//calculate which tile was selected 
tilex=(ptMouse.x-TILEPANELX)/TILEWIDTH; 
tiley=(ptMouse.y-TILEPANELY)/TILEHEIGHT; 
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tilenum=iTileTopt+tilex+tiley*TILEPANELCOLUMNS ; 
//check for valid tile 
if(tilenum&tsTileSet.GetTileCount()) 

{ 


//assign current tile 
iTileSelected-tilenum; 
} 
return(0);//handled 
} 
//scroll tileset up 
SetRect(&rcZone, TILEPANELX,O, TILEPANELX+ 
TILEPANELWIDTH, TILEPANELY) ; 
if (PtInRect(&rcZone, ptMouse) ) 
{ 
//check if we can scroll up 
if(iTileTop>0) 
{ 
//scroll up 
iTileTop--TILEPANELCOLUMNS ; 


} 

//scroll tileset down 

SetRect(&rcZone, TILEPANELX, TILEPANELY+ 
TILEPANELHEIGHT , TILEPANELX+ 
TILEPANELWIDTH, 600); 

if (PtInRect(&rcZone, ptMouse) ) 

{ 


//check if we can scroll down 
if((iTileTopt+TILEPANELCOLUMNS)< 
tsTileSet.GetTileCount()) 
{ 


//scroll up 
iTileTopt=TILEPANELCOLUMNS ; 


} 
return(0);//handled 
}break; 
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A FEW WORDS ABOUT THE 
TILENIAP EDITOR 


Even though the sample map editor doesnt do much, it does illustrate important points about all map edi- 
tors. Just about every map editor I've made or used includes something similar to the map panel and some 
thing similar to the tile panel (although usually with a more obvious way of scrolling through the tileset). 


Al TILE-BASED EXAMPLE: REVERS! 


N ow that we've delved a bit into the tile based world, let's put this knowledge into practice T he first 
example Га like to show you is a game called R eversi. (It's also called О thello, but O thello is trademarked 
by M Шоп Bradley, so we'll call ours Reversi.) 


T he basic idea of Reversi is pretty simple. In case you arent familiar with the game or the rules, heres a 
brief breakdown: the game pieces are a board, divided into an 8x8 grid of 64 squares, and at least 64 two- 
sided pieces of contrasting color (usually black and white). At the beginning of the game, the center four 
squares are filled with pieces, two black and two white, as shown in Figure 10.18. 


Figure 10.18 


The Reversi board at 
the beginning of play 
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Two players alternate taking turns placing a single piece on the board and capturing any opposing pieces 
that they outflank. To outflank means to have one piece of your color on each end of a horizontal, verti- 
cal, or diagonal row of your opponent's pieces. You cannot outflank across your own pieces or across open 
squares. If on a player's turn there is no valid square on which he can play a piece and outflank his oppo- 
nent, he forfeits that turn. Play progresses until no valid moves for either player are left (usually this hap- 
pens when the board is full, although it can happen earlier). 


H aing said that, let's make the game. 


DESIGNING REVERS! 


| have М ilton Bradley's Othello sitting on my game shelf, so | looked to that to mode this дате. T he 
board is green with a black border separating the squares. Two cells in from the corners, there is a small 
square on the junction of the black lines, apparently to separate the sides and corners from the middle of 
the board. T he pieces are double-sided and two-colored, with white on one side and black on the other. 


| wanted to have some sort of method with which to highlight the possible squares to which the player can 
move on his turn, so | also made yellow versions. | wanted an animated "flipping over" of the pieces, so 
made a sequence of ellipses to show that. Figure 10.19 shows the tileset | came up with for this game Y ou 
can also find it in the source code for this chapter, under the name IsoH ех10 4.bmp. | used magenta 
instead of black as the transparent color. (O riginally, | considered having a black piece instead of the dark 
gray that | later settled on.) 


Figure 10.19 


Tileset for Reversi 
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T he first row of tiles is the nonhighlighted version of a board background tile Т he second row is the 
highlighted version. Rows three through five are the animation sequence for the piece flip, with the actual 
pieces for both sides on opposite ends of the sequence. T һе last row consists of extra graphics | needed to 


finish up the U I. T here is а red square to represent the last move made, and four icons to show the AI level 
chosen for the players. 


Al LEVELS 


| decided on four levels of Al for this example (none of them are very difficult to beat). T hese levels are 
represented by constants defined in the source. 


//ai levels 


const int 
const int 
const int 
const int 
const int 


AT_HUMAN=0 ; 
AT_RANDOM=1; 
AT_GREEDY=2; 
AT_MISER=3; 
AI. COUNT-4; 


Table 10.4 explains these Al levels. 


Table 10.4 Al Levels andTheir Tactics 


Level Tactic 

AI HUMAN None.W aits for input from the mouse. 

AI RANDOM Picks a random valid move. 

АТ. GREEDY Picks the valid move that will give it the greatest score. 

AT MISER Picks the valid move that best limits the opponent's movement. 


NOTE 
AI. COUNT is not anAI level, but rather a constant to keep 


track of the number of levels that exist, in case you later want 
to add more Al levels. 
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Game STATES 


As with all games, there are a number of major game states in which Reversi might dwell at any given time. 
| was able to reduce it to only five states. 


//game states 

const int GS_NONE=-1; 

const int GS WAITFORINPUT-0; 
const int GS NEWGAME-21; 
const int GS NEXTPLAYER22; 
const int GS FLIP23; 


Table 10.5 explains these states. 


Table 10.5 Revers Game States 


Game State Meaning 

GS NONE A neutral state.The board is drawn, but no other action takes place. 

GS WAITFORINPUT If the current player is computer-controlled, a move will be made. 
Otherwise, it waits for mouse input. 

GS NEWGAME Sets up a new game 

GS NEXTPLAYER Checks for game over. If the game is not over, it selects the next 
player. 

GS FLIP In this state, the pieces captured during this turn are taken through 


the animation sequence. 


TILE INFORMATION STRUCTURE 


Reversi may seem like a simple board game, but the struct that keeps track of the tile information is a little 
more complicated than just a simple array of integers. 


//tile information structure 
struct REVERSITILE 
{ 
int iTileNum;//base tile number for square 
bool bHilite;//hilited, or not hilited 
int iPiece;//piece occupying square 
bool bLastMove;//last move made 
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Тт =Мига 
T his member keeps track of the background and specifies one of the first five tiles of the tileset. M ost 


squares contain tile zero, but a few contain the others. | could have easily just used tile zero for the entire 
board, but that would have been boring. 


RBHILITE 


W hen the current player can make а valid move on a given square, bHilite is true. If the square is not a 
valid move for the player, hHilite is false bHi1ite, when used in conjunction with iTi1eNum, provides 
the background tile W hen bHilite Is true, 5 is added to iri1eNum. 


ІРЛЕСЕ 


T his member has four meaningful values: PIECEEMPTY(-1), PIECEBLACK(0), PIECEWHITE(1), and 
PIECETRANSIT(2).T he empty, black, and white are self-explanatory. Т he transit piece is for use with the 
GS FLIP State. It specifies which pieces undergo the animation sequence. 


RLASTMOVE 


Only one square at a time will ever have bLastMove Set to TRUE. bLastMove specifies that the red rectangle 
(tile 25 of the tileset) is to be shown over the background, thus indicating that the square was the most 
recent move. Keeping track of this is not absolutely necessary, but | find it helpful when playing the game. 


SCORE INDICATION 


| wanted to have a score indication that did not require a font to implement. | could have used some extra 
tiles for the numerals 0 through 9 in the tileset, but | just didnt like that idea. Instead, | decided to use 
vertical stacks of the pieces alongside the board. Both stacks are on the left side of the board, so they can 
easily be compared to see who is winning. 


Al LEVEL CONTROL 


| didnt want to make a configuration screen, so | had to work in some sort of AI leve control right on the 
screen itself. W hat | came up with was to put two of the colored pieces in the bottom-left corner (aligned 

with the score stacks), and | would blit icons representing what A1 levels controlled which color. T he icons 
are from the wingdings font, but | colored them in to make them look better. 
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TILE-BASED FUNDAMENTALS 


IMPLEMENTATION OF REVERS! 
With the design in mind, heres some of the implementation detail for Reversi. Because of space concerns, 


| cant get into every minute detail, but the full source code can be found in IsoH ex10_4.cpp. I'm going to 
concentrate on the main game loop (Prog Loop) and break it down by game state. 


MAJOR Сова VARIABLES 


Reversi uses full-screen D irectD raw, set to an 800x600x16 resolution. Т he major global variables are 
shown next. 


Your basic run-of-the-mill 1DirectDraw7 pointer: 


//IDirectDraw/ Pointer 
LPDIRECTDRAW7 lpdd-NULL; 


A primary surface and the attached back buffer: 


//surfaces 


LPDIRECI 
LPDIRECI 


T he main 


[DRAWSURFACE7 lpddsMain-NULL; 
[DRAWSURFACE7 lpddsBack-NULL; 


tileset to contain all of the graphics used: 


//tileset 
CTileSet tsReversi; 


T he main 


board and a temporary storage area: 


//the board 


REVERSI 


TILE Board[8][8]; 


//backup board 


REVERSI 


[ILE BackUpBoard[81[8]; 


A variable to keep track of the current player: 


//current player 
int iPlayer-0; 


An animation counter for use during 65 FLIP: 


//counter for animated “flipping” of pieces 
int iAnimation-0; 


ISOMETRIC GAME PROGRAMMING wItTH, DIRECTX 7,0 


//ai 


An array to keep track of what Al controls each color: 


level for the players 


int iAlLevel[2]; 


T he main game state: 


//gamestate 
int iGameState=GS_NONE; 


ALL GAME STATES 


Regardless of game state, a certain amount of code runs each loop. Т his code prepares а new frame for the 
game and then displays it. 


//clear out back buffer 
DDBLTFX 


рові] 


Траа 


//sh 


ddbltfx; 


[FX ColorFill(C&ddbltfx,0); 


sBack-»B1t(NULL,NULL,NULL,DDBLT WAIT | DDBLT COLORFILL,&ddbltfx); 
[JM 


OW 


TTED CODE*** 
the board 


ShowBoard(); 


//sh 


OW 


the scores 


ShowScores(); 
ow players 
ShowPlayers(); 


//sh 


/ [fli 
Траа 


р 


sMain-»Flip(NULL,DDFLIP WAIT); 


T his bit is pretty simple. First, you clear out the back buffer, and then you draw the board, draw the 
scores, draw the Al levels, and finally flip the page. It’s a pretty to-the-point snippet. You can take a look at 
the constituent functions in the source code if youre interested. T he following sections offer a brief run- 
down of the major function calls. 
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FSHOWROARD 
T his function loops through all of the board squares and follows approximately these steps: 


1 Based on iTileNum and bHilite for this board square, determine which tile to use as the 
background tile. 

2. Determine what piece, if any, is resting on this square. If it is PIECEBLACK or PIECEWHITE, 
show the appropriate tiles. If it is PIECETRANSIT, determine what tile to show based on the 
global variable i Animation. 

3. If this square has bLastMove set, put the red square on top. 


SHOwWSCORES 


T his function shows the scores for each color, representing the score with a vertical stack of pieces. For 
each piece on the board, ShowScores renders one piece. Т he first piece is rendered with the top of the 
piece at y=0, and у increases by 4 for each additional piece on the board. Т his allows а nice, easy way to 
tell who is winning while avoiding numerals. 


FSHOWPLAYERS 


T his function shows the Al levels of both colors in the bottom-left corner of the screen. A black piece sits 
next to a white piece On top of these pieces the function renders an icon that represents the AI level for 
that color. A mouse represents a human player, and computers with the numerals 1, 2, and 3 represent the 
three levels of computer Al. 


GS NONE 


T his game state does almost nothing. In fact, there is no case for it in the iGameState switch in 
Prog. Loop. Only in ће ww LaurrONUP event handler does 65 NoNE get a mention. If the board is clicked 
on while іп cs NoNE, the game moves to Gs. NEWGAME. 


case WM LBUTTONUP: 
{ 


//grab mouse position 

POINT ptMouse; 

ptMouse. x=LOWORD(1Param) ; 

ptMouse. y=HIWORD(1Param) ; 

//test rectangle 

RECT rcTest; 

//get tile width and height 

int iTileWidth=tsReversi.GetTileList()[0].rcSrc.right- 
tsReversi.GetTilelList(O)[0].rcSrc. left; 
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int iTileHeight-etsReversi.GetTilelist()[0].rcSrc.bottom- 
tsReversi.GetTileList()[0].rcSrc.top; 
//calc board rect 
SetRect(&rcTest,(400-iTileWidth*4), 
(300-iTileHeight*4),(400+iTileWidth*4), 
(300+iTileHeight*4)); 
//point on board? 
if(PtInRect(&rcTest, ptMouse) ) 
{ 
//***XCODE OMITTED 
//if a game is over, start a new game by clicking on the 
board 
if(iGameState--GS NONE) 
{ 


iGameState=GS_NEWGAME; 


} 
//***CODE OMITTED*** 
break; 


(аа NEWGANMNE 


GS NEWGAME starts anew game, and is actually one of the simpler game states. First, it makes a call 
to SetUpBoard, which does all of the reinitialization necessary to start out with a clean board. T hen it sets 
the player to PLAYERTWO and sends the game into cs. NExTPLAYER. | could have done this another way, by 
setting iPlayer to PLAYERONE and sending it into GS_WAITFORINPUT. 


case GS NEWGAME: 

{ 
//clear the board 
SetUpBoard(); 
//set player 
iPlayer-PLAYERTWO; 
//change game state 
iGameState-GS NEXTPLAYER; 

break; 
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GS_NAITFORINPUT 


T his game state is the central game state. All Al moves are done here. W hen the game first enters 
GS WAITFORINPUT, it checks the current player's Al level. If Al_HUMAN is indicated, the game does nothing. 
If it isa computer Al (AI. RANDOM, AI_GREEDY, Or AI_MISER), it calls the appropriate Al function. 


case GS_WAITFORINPUT: 
{ 


//make move appropriate to the Al 
switch(iAILevel[iPlayer]) 
{ 
case AI_RANDOM: 
{ 
MakeRandomMove(iPlayer); 
}break; 
case AI_GREEDY: 
{ 
MakeGreedyMove(iPlayer); 
}break; 
case AI_MISER: 
{ 
MakeMiserMove(iPlayer); 
}break; 


} 
}break; 


N ote that the Al level of A1 HUMAN isnt even represented in this snippet. T hat is because all of the 
AL HUMAN Stuff for GS_WAITFORINPUT is handled in the wM_LBUTTONUP event handler. (Al and GS and 
WM...oh my!) 


/[***CODE OMITTED*** 

//point on board? 
if(PtInRect(&rcTest,ptMouse)) 
{ 


//if we are waiting for input and the ai is “human,” check for inside the 
board 
if((iGameState--GS WAITFORINPUT) && 
(iAILevel[liPlayer]--AI. HUMAN) ) 


//find board position 
int BoardXe(ptMouse.x-rcTest.left)/iTileWidth; 
int BoardY-(ptMouse.y-rcTest.top)/iTileHeight; 
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//check for a valid square 

if(ValidMove(iPlayer,BoardX,BoardY)) 

{ 

//make the move 
MakeMove(iPlayer,BoardX,BoardY); 
SetLastMove(BoardX,BoardY); 
iGameState-GS FLIP; 


} 
/[***CODE OMITTED*** (the GS NONE check) 


} 
/[***CODE OMITTED*** 


сш FLIP 
After a move has been made, the newly captured pieces are not set to the color of the player who captured 
them. Instead, they are changed to PIECETRANSIT, and Gs_FLIP is the game state responsible for making 
sure that the animation sequence for capturing these pieces is shown. 


case GS_FLIP: 
{ 
switch(iPlayer) 
{ 
case PLAYERTWO: 
{ 
if (iAnimation==0 ) 
{ 
FinishMove(iPlayer); 
iGameState-GS NEXTPLAYER; 


iAnimation-; 
} 
break; 
case PLAYERONE: 
{ 
if(iAnimation==14) 
{ 
FinishMove(iPlayer); 
iGameState-GS NEXTPLAYER; 
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jAnimationt++; 


}break; 
} 
}break; 


T he main purpose of Gs_FLip isto modify iAnimation, which controls what part of the animation 
sequence you are оп. W hen it is PLAYERONE'S turn, i Animation Starts at 0 and is incremented until it hits 
14, at which point the move finishes (by a call to FinishMove, which changes all PIECETRANSITS to a 
color'5 piece). Similarly, on PLAvERTWOS turn, iAnimation Starts at 14 and moves backwards until it hits 
0. In ether case, after cs_FLIP is finished, the game moves into GS. NEXTPLAYER. 


Gm, NEXTPLAYER 


After a move has been completed, this game state checks to see if the game is over or sets the next active 
player. If the game is over (there are no valid moves for either player), it sends the game into as_None. If 
the game is not over, it checks to see if the opposing player has a valid move. If the opposing player does 
not have a valid move, it goes to GS_WAITFORINPUT Without changing the player. If the opposing player 
does have a valid move, it sets the current player to the opposing player and moves into GS. WATTFORINPUT. 


case GS NEXTPLAYER: 
{ 


//scan for moves 

ScanForMoves(iPlayer); 

//if no more valid moves, game over 
if(C!AnyValidMoves(PLAYERTWO)) && (!AnyValidMoves(PLAYERONE))) 


iGameState=GS_NONE; 


else 


//find if opponent has any moves 
if (AnyValidMoves(1-iPlayer)) 
{ 

iPlayer-l-iPlayer; 


ISOMETRIC GAME PROGRAMMING WITH, DIRECTX 7,0 


//scan for moves by current player 
ScanForMoves(iPlayer); 


//get next move 
iGameState-GS WAITFORINPUT; 


break; 


MISCELLANEOUS ACTIONS 
Before we complete our treatment of Reversi, | have a few last things left that | want to point out. 


= Changing Al Levels. D uring every loop, the current Al levels are shown at the bottom left of the screen. You 
can change the level by clicking on the indicators. Each time you click, you increase the A1 level by 1. Clicking 
on the highest level brings you back to the lowest level (АІ HUMAN). 

= Keyboard Controls. Esc exits the program, no matter what game state you are in. F2 starts a new game, по 
matter what game state you are in. 


FINAL WORDS ON REVERSI 
T his simple little game of В eversi is far from complete Y еб, it is fully functional and playable, but it lacks 
any extras. Just like the Breakout game in the preceding chapter, I'm leaving it for you to finish. Н eres a 
brief list of features | think it needs: 

= A title screen 

= Some sort of "bells and whistles’ when you win 

= Sound/ music 


And I'm sure you'll come up with 50 ways to improve the program. Н ave fun with it. 


SUMMARY 


In this chapter, you took a step into a larger world. You explored the power that graphical tiles can give 
you. | went into great detail on the topic of tileset management, and for good reason. From here on out, 
just about everything you do will be done using the cr: 1eset class, in some fashion or another. 
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his chapter marks a new beginning. All of the preparatory information and discussion is over, and 

it is at last time to sally forth into the wonderful world of isometric and hexagonal graphics. T his 
is not to say that what we have discussed so far has been meaningless. To the contrary! All of the previous 
topics have been building up to this chapter and to the rest of this book. 


T his chapter takes you on a ride through isometric land. M ainly, | will talk about the special considera- 
tions you have to keep in mind when creating isometric or hexagonal tiles, rendering these tiles, and inter- 
acting with then on-screen. 


INTRODUCTION TO ISOHEX 


So, what is “150Н ех”? Simply, it's a word | made up. A couple of years ago, | was sitting around playing 
Sid M аег5 C ivilization || and generally being a nonfunctional human being. Of course, I'd been a game pro- 
grammer for many years, but most of my stuff dealt with the normal top-down rectangular tiled method- 
ology that was common in the waning days of DOS. 


| was quite impressed with the look of Civilization 11. It looked a heck of alot better than the original. T he 
isometric view gave it a semi-3D look. N aturally, | just had to know how it was done. So | looked through 
the directory in which Civilization || was installed, and | viewed the several GIF files that stored the images. 
T hen | started playing around with similar tiles in my own experiments. 


A friend of mine, Isaac Vanier, posted a question on a message board about how to take mouse input and 
determine what tile it was on in an isometric map. H aving toyed with the idea of isometric tiles, | sent 
him an e-mail answering his question. Apparently, my little e-mail helped him out quite a bit, because he е- 
mailed me back, telling me that | should write an article about it. 


| thought surely there must be resources on how to do this stuff, and that writing another article about it 
would be unnecessary. So | scoured the Internet for a trace of isometric tutorials, or at least somehing about 
them. N eedless to say, there wasnt much out there. | saw bizarre linear algebra computations, and some 
pretty crazy and not-very-optimized ways to do isometric tiles. T here was one exception— an article by Jim 
Adams called “Isometric Views,” written in 1996 (keep in mind, | was doing this search in 1998). T his 
article was originally a newsgroup post by M r. Adams and had been "translated" into article form. It was 
just about the only isometric article you could find on the N et. T he article had a bunch of god-awful 
ASCII art, and it didnt talk about mapping screen coordinates to tile coordinates. | decided to write my 
article after all. 


Originally, | put my article on my Web page (you know. . . theW eb space that your ISP gives you) and gave 
links to it from message boards. E ventually, a few people linked to it. Finally M att Reiferson, the 
W ebmaster of GPM ega (the most popular amateur game programming site at that time) contacted me 
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and asked if he could put the article on his site. | agreed. М y little article (and a sequel that | wrote а 
while later) became quite popular. Eventually, some of the other guys who hung out in the GPM ega chat 
room and | formed our own site, Sweet.O blivion. Eventually Sweet.O blivion joined with other sites to 
form GameD evnet. T hroughout these events, this little article has followed me. Currently, it is the 27th 
most frequently accessed article on GameD ev.net. 


W hat does this have to do with the word "IsoH ex" ?W dl, that little article first coined the term. T hat arti- 
deis also the primary reason you are reading this book. W ithout that article, | would never have been 
asked to write this book. (1 admit, it's more complicated than that, but it was a key component.) 


So, the original question remains: what is 150Н ех? IsoH ex is, quite naturally, a combination of the words 
isomeric and hexagonal. An isometric projection is a 3D projection that does not correct for distance (in 
other words, something 30 tiles away is just as big as something 10 tiles away). T he isometric projection is 
one of a family of ахопотвгіс projections. (T he meaning of axonometric isnt terribly important. It's an 
engineering term.) Rhombuses, or diamond shapes, are usually used to represent an isometric tiled world. 
Figure 11.1 shows a field of isometric tiles. 


= Qut Qe ис uS ME ie Figure 11.1 


An isometric tile field 


eee eee 


Н ex agonal means six-sided. As far as tiled graphics go, there is almost no difference between an iso-tiled 
world and a hex-tiled world. T he difference is all in connotation and convention (meaning that on а hex 
map, you can move in six directions instead of eight, as with iso). H ex maps are commonly used by 
paper-and-pencil R PG ers and by strategy gamers, such as those who play Battldeh. Figure 11.2 shows 

a hexagonal field. 


ISOMETRIC GAME PROGRAMMING wItTH, DIRECTX 7,0 


Figure 11.2 
A hexagonal tile field 


T he main difference between an iso tile and a hex tile is that the two halves of an iso tile are split apart, 
and a rectangular area is inserted between them, as shown in Figure 11.3. 


Figure 11.3 


Iso to hex 
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T here really is not much of a difference between iso and hex as far as programming goes. It is mainly a 
user interface issue. At this point, | think you've probably had more than you want to hear about 150Н ex, 
and you would rather start doing stuff. | dont blame you, so let's get to it! 


TSOHEX TILES VERSUS 

RECTANGULAR TILES 

So far, the tile based examples have always used rectangular areas that contain the tiles; this is not going to 
change. W hat will change is how you will render them in relation to one another. 


Take, for example, a 64x64 rectangular tile, like the ones used in the Reversi example іп the preceding 
chapter. In order to blit these tiles onto a grid, you simply use multiples of 64, as shown in Figure 114. 


Figure 11.4 


M aking rectangular 
tiles flush 


IsoH ex tiles cant do this (or, at least, most of them cant). Since only a portion of the rectangle is filled 
with the actual tile the rectangles containing the tile have to overlap, both vertically and horizontally, as 
shown in Figure 11.5. 
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Figure 11.5 


Making IsoH ex tiles flush 


As you can see, the IsoH ex tiles have to be shifted over by half a tile on alternating rows, whereas no 
adjustment is necessary for rectangular tiles. T his brings up another important point: blitting order. W ith 
rectangular tiles, you can blit in any order you want— left to right, right to left, top to bottom, bottom to 
top— and the map will look right no matter what, because none of the tiles overlap. 150Н ex tiles, however, 
often have something "sticking up out of them,” like a tree or a building or a unit. T here are some impor- 
tant ramifications of this. 


= Rule 1. 150Н ex tiles must be blitted in a manner so that no tile is blitted after а tile that is "in front” of it. 
T he methods of doing this are based on the type of tilemap used. ІЛІ get into this later. 

= Rule 2. If only a small portion of the screen has to be updated, you cannot just blit the tile that changed. 
You have to blit neighboring tiles as well, and you have to make certain that you follow Rule 1 while doing 
50. Clippers come in quite handy to help with this. 

= Rule 3. Except for the diamond tilemap, you must avoid as much as possible showing the jagged edges of the 
етар (they are the most severe on staggered maps). Т his isnt really a rule; it's more a matter of aesthetics. 


1SOHEX TILEMAPS VERSUS 
RECTANGULAR TILEMAPS 


Rectangular maps are maintained by а two-dimensional array in most cases. T he same is true of 150Н ex 
maps. H owever, the meaning of the x- and y-coordinates changes somewhat. [п a rectangular map, increas- 
ing x moves east, and increasing y moves south. In an iso tilemap, depending on type, increasing x might 
mean moving southeast, and increasing y might mean moving southwest. 
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W һу? Because of the overlap. Every other row or column has to be shifted half a tile— either right, left, 
up, or down— in order to make the tiles flush with one another. | showed you this in the preceding sec- 
tion. For this reason, increasing y by 1 almost never means to move south. Н owever, in most cases, increas- 
ing x by 1 does mean to move east. 


T his makes navigating an IsoH ex етар a bit more involved than navigating a simple rectangular map. 
You have to use a lookup table (and sometimes two) to get it right. Dont worry. | wont leave you hanging; 
ІЛІ show you everything you need to know, when you need to know it. 


ISOMETRIC ENGINES VERSUS 
RECTANGULAR ENGINES 


T here are several components to any good tile engine. If you want to make tile based games, it's smart to 
have a good set of functions or classes to wrap up the tricky stuff for you. Т his is especially important in 
ISOH ex, since the tilemaps are trickier than in normal rectangular tiles. 


TILEPLOTTER 


A T ilePlotter is used to convert map coordinates (indices into the tilemap array) into world space coordi- 
nates. In a rectangular engine, you simply multiply by the width and height of the tile, since x always goes 
east-west and y always goes north-south. In isometric engines, the meanings of x and y change, and at least 
one of them moves in a diagonal direction, which changes the equation. О nce aT ilePlotter has converted а 
map coordinate into a world coordinate, it can be from there translated into view and screen coordinates. 


MousEeEMAFPF 


A M ouseM ap goes the opposite way of aT ileP lotter. It takes a world coordinate and converts it into a 
map coordinate. A M ouseM ap is necessary because of the irregular (nonrectangular) shape of the isome- 
ric and hexagonal tiles. In a rectangular tile engine, а M ouseM ap is unnecessary, because all of the rectan- 
gles are already. . . well, rectangular. 


In an iso or hex engine, you still need to check to see if the mouse is in rectangular areas, because of the 
fact that it is computationally inexpensive to do so. You could instead use equations or some other method 
to check for being within tiles, but the math is just too weird and too complicated, and M ouseM aps make 
them unnecessary. T he M ouseM ap itself is a second step in the world-to-map conversion. First, the x and 
y coordinates are divided by the M ouseM ap width and height, and then the remainders are fed into the 

M ouseM ap to determine which tile corresponds to the pixel coordinate. 


So, why is this important component called a "M ouseM ap"? Although it has many uses as the reciprocal 
of theT ilePlotter (which has a name befitting its function), the most important use for the M ouseM ap is 
taking a mouses (or other pointing devices) screen coordinate and finding the corresponding 

map coordinate. 
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TILEWALKER 


T heT ileW alker is absolutely necessary, although most iso folks wouldnt list it as a major component. [п 
my opinion, it is just too darned important not to be all on its own. A T ileWalker does just one thing: 
move from map coordinate to map coordinate. T his might seem a pretty tame feature, but it is essential for 
using a M ouseM ap, moving units, and pathfinding. 


M inimally, aT ileW alker can consist of a single function that returns a pornT with the following parame 
ters: a POINT specifying a map coordinate, an int specifying direction of movement, and another int stating 
how many map coordinates to move. 


THE THREE TYPES OF 
1SOHEX TILEMAPS 


T here аге three types of 150Н ex tilemaps: slide, staggered, and diamond. Each has its own set of quirks, its 
own methods of rendering, its own way of representing a tilemap, and its own method of navigating them. 
| will briefly introduce them here and then explore them more fully in the next three chapters. 


As far as an iso tilemap is concerned, any of these types of map is usable, depending on what game you 
are making. For hex, however, staggered is the most commonly used map type, although | have сееп a dia- 
mond map using hex tiles. 

T he explanation of each type of map briefly covers some of the problems you face in designing each of 
the core engine components. 


GLIDE MAPS 


T he slide tilemap is probably the easiest to render, navigate, and interact with. U nfortunately, it has limited 
uses. It's mainly used to scroll action games. 


U sually, a slide map has a horizontal x axis and a diagonal y axis, although it is possible to have a vertical y 
axis and a diagonal x axis. Figure 11.6 shows a few samples of what slide maps can look like. 


1SOMeETRIC/SHEXAGONAL TILE OVERVIEW EAE 


Figure 11.6 


Slide maps 
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T ilePlotting, M ouseM apping, and T ileW alking in а slide map are all very regular and consistent. T he tiles 
are blitted in horizontal rows top to bottom. 


STHGGERED MAPS 


For most serious isometric/ hexagonal turn-based strategy games, the staggered map is king. Each new row 
is alternately shifted one-half of a tile left or right (certain hex maps turned on their sides shift up or 
down). T his results in a zigzag pattern of tiles, as shown in Figure 11.7. T he x-axis usually is horizontal 
(increasing to the east), and the y-coordinate is alternately southeast and southwest. Staggered maps are 
best suited for maps that wrap around (move from one edge to the other) and for times when you want to 
completely fill a rectangular area. T his is also the most common type of hex map. 


Figure 11.7 
Staggered maps 
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Staggered maps are the most irregular of the three. T ilePlotting, М ouseM apping, and T ileW alking are 
all slightly complicated due to the offset of every other row. T he tiles are blitted in horizontal rows, top 
to bottom. 


DIAMOND MAPS 


T he diamond map is by far the most popular for real-time strategy games and “sims.” T he edges of this 
type of map are the least offensive (Staggered maps have “tattered” edges, slide maps have “tattered” tops 
and bottoms, and diamond maps are smooth.) 


U sually, the x-axis increases in the southeast direction, and the y-axis increases in the southwest direction, 
although this isn't absolutely necessary to follow my configuration exactly. [п diamond maps, the only 
requirement is that both the x- and y-axis are diagonal. Figure 11.8 shows an example of a diamond map. 


Figure 11.8 


Diamond map 


Based on the “turned on its side” nature of diamond maps, you would think that they were the most com- 
plicated to make. In reality, they are not, but the equations are a little weird for theT ilePlotter (both the x 
and y of the map coordinate are used to calculate the tiles world coordinate). T пет ileW alker is complete 
ly regular, and the M ouseM ap is similarly quite normal.T he only odd thing about the M ouseM ap is that 
often the world coordinates can be negative, and the divisions and remainders have to be adjusted for that. 


ISOHEX TILESETS AND THE IMPORTANCE 
OF ANCHORS 
W hen making isometric games, you use tilesets just like when you make rectangular games. Н owever, the 


tile anchors become much more important. In the rectangular example from the preceding chapter, you 
simply put the tile anchor at the upper-left corner of thetile, and you didnt have to worry about it. 
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Iso and hex games dont provide that luxury. You have to deal with countless objects, all of which аге ап 
odd shape. You have to ensure that when you have everything rendered, the images line up. 


For the most part, | handle this by putting the anchor in the center of an iso or hex tile. Figure 11.9 
shows what | mean. U sing a centered tile anchor like this makes selecting anchors for nonbackground 
images (like trees or units) a lot easier, because you then have to put the x anchor at the horizontal center 
of the image and the y anchor somewhere near the base of the image. Figure 11.10 shows a suitable 
anchor for a unit tile, and Figure 11.11 shows what these two tiles look like when used together. 


Figure 11.9 


An isometric tile, with 
center anchor 


Figure 11.10 


Foreground iso image 
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Figure 11.11 


Background iso tile with 
foreground image added 


Just keep in mind that you want a tile anchor scheme that is easy to manage and that doesn’t complicate 
the core engine. T he easier you make it on your artists, the less they will revolt. O h, and be sure to throw 
them a Dr. Pepper once in a while, even if they dont really deserve it. 


SUMMARY 


You are now ready for what lies ahead. T he next few chapters explore the different types of iso tilemaps, 
and you'll make a few games along the way, too. M ainly, you will put down the foundations of an honest- 
to-goodness 2D iso tile engine T he tools to make awesome isometric games are just a few pages away! 
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his chapter begins the first of three chapters that cover the various types of IsoH ех tilemaps. T his 

chapter covers the simplest (and least commonly used) type: slide maps. Even if you dont like slide 
maps, you should probably read this chapter because it covers some of the explanations common to all 
types of 150Н ex mapping techniques, including the basis for the three major components of an 150Н ex tile 
engine, which | mentioned briefly in the preceding chapter. 


T he first question that might come to mind is why I'm calling this particular type of IsoH ex етар а 
“slide map.’ W hen | was originally going through and classifying 150Н ex items, | had to come up with 
terms for these maps. W ith slide maps, | noticed that while the x-axis was normal, the y-axis “slides” off 
to the side. H ence, | named them “slide maps.” T here really is no official term for them, so | made one up. 
Simple enough? 


INTERLOCKING ISOHEX TILES 


You havent really learned about interlocking 150Н ex tiles yet. | told you that the rectangles containing 
І5ОН ex tiles overlapped, but not much more than that. Before you can proceed, you've got to be able to 
interlock the tiles— that is, make the diagonal edges match up with no missing pixels. To learn how to 
interlock the tiles, you first have to take a look back at how rectangular tiles work. 


As you сап sæ in Figure 12.1, the interlocking of rectangular tiles is quite simple. Т he colored pixels are in 
the upper-left corners to represent the anchors, which makes visualizing the interlocking easier. То move 
east (to the right of the screen), you simply add the width of the tile to the x-coordinate То move south 
(down), you add the height of thetile to the y-coordinate. From these two calculations, you can infer that 
to move west (left), you simply subtract the width from x (moving west is the opposite of moving east). To 
move north, you simply subtract the haght from y. As soon as you have the four cardinal directions 
(north, east, south, and west), you can construct the other four directions (northeast, southeast, southwest, 
and northwest) by combining the other directions. Table 12.1 shows the x and y modifications necessary 
for a rectangular tile system using TileWidth*TileHeight tiles. 
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Figure 12.1 


Rectangular tiles interlocking 


Table 12.1 Rectangular Tile Plotting 


Direction Change x Change y 
North 0 -TileHeight 
N ortheast +TileWidth -TileHeight 
East +TileWidth 0 

Southeast +TileWidth +TileHeig 
South 0 +TileHeight 
Southwest -TileWidth +TileHeight 
W est -TileWidth 0 
Northwest -TileWidth -TileHeight 
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NOTE 


І use compass directions (north, south, 
east, and west) rather than up, down, 
right, and left, not to confuse you, but 
rather to clearly indicate the absolute 
direction. T he compass directions have 
absolute meanings, whereas left and 
right do not, since a character that is fac- 
ing toward you has a different left and 
right than one facing away from you. 


Tile Width 


Figure 12.2 is a more graphical representation of 
Table 12.1. | fed that a visual is much better at con- 
veying this than just a simple table. It's the whole "a 
picture is worth a thousand words" idea. Based on this 
table, and based on the direction of the x- and y-axis 
(x increases to the east, and y increases to the south), 
you can come up with an equation to determine 
where to blit your rectangular tiles: 


//TileX/TileY are the pixel positions (in 
world space) for the tile being blitted 
//MapX/MapY are the map coordinates of 
the tile 

TileX-MapX*TileWidth 
TileY-MapY*TileHeight 


Figure 12.2 


A graphical representation 


of Table 12.1 
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You have been using these calculations all along. You just havent really done any sort of analysis as to why 
they work. 


N ow take a look at some standard iso and hex tiles and do some similar figuring for plotting adjacent tiles. 
Figure 12.3 shows some standard iso and hex tiles (standard meaning similar to what we will use in this 
book). Т he anchors are marked. 


Figure 12.3 


Standard iso and 
hex tiles 


Figure 12.4 shows the iso and hex tiles grouped with others of the same kind. | will usethese to show 
positional calculations between tiles, just like! did with rectangular tiles. 


Figure 12.4 


Iso and hex tiles 
together 
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ІП iso, moving east moves by the width of the tile Similarly, moving south moves by the height of the tile 
(not exactly, but close enough). T hus, moving north or west is the opposite of these directions. Н owever, if 
you look at moving in a diagonal direction, you can see that a tile is half of the width to one side horizon- 
tally and half of the height vertically offset. Table 12.2 shows the changes in x and y based on the direc- 
tion traveled. 


Table 12.2 IsoTile Plotting 


Direction Change x Change y 
North 0 -TileHeight 
N ortheast +TileWidth/2 -TileHeight/2 
East +TileWidth 0 

Southeast +TileWidth/2 +TileHeight/2 
South 0 +TileHeight 
Southwest -TileWidth/2 +TileHeight/2 
W est -TileWidth 0 

Northwest -TileWidth/2 -TileHeight/2 


Figure 12.5 shows graphically what is contained in Table 12.2. Based on these calculations, it is obvious 
that at least one axis of the tilemap has to be on a diagonal. If not, the tiles positioned based on 
TileWidth/2 and TileHeight/2 would be skipped completely, leaving the map full of holes, as shown in 
Figure 12.6. 
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Н ex tiles are very similar to iso tiles, with one major difference: Two directions of movement are disal- 
lowed— in this case, north and south. W hile reading this discussion on hex tiles, keep in mind that the 
tiles could easily be turned on their sides, and east-west movement disallowed instead. 


T he movement to the east is dependent on ri 1ewidth, but the southeast movement is based on 
TileWidth/2 for x and a y value that depends on the shape of the tile (mainly, the height of the vertical 
lines). For the time being, | will name this value HexRowHe i ght, since it has no particular relationship to 
the tiles height. 


Table 12.3 is similar to Table 12.2, with the word HexRowHeignt substituted for the word TileHeight. 
Also, north and south are missing. Table 12.3 shows plotting from tileto adjacent tile in a hex map. 


Table 12.3 HexTile Plotting 


Direction Change x Change y 
Northeast +TileWidth/2 -HexRowHei ght 
East +TileWidt 0 

Southeast +TileWidth/2 +HexRowHei ght 
Southwest -TileWidth/2 +HexRowHeight 
W est -TileWidt 0 

Northwest -TileWidth/2 -HexRowHeight 


Figure 12.7 shows the calculations in Table 12.3 in a more graphical and easy-to-understand manner. 
Turning the hex on its side is something | wont show here, since it is much the same as the hexes | ‘ve 
already shown, with some of the x and y changes flipped. 
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Figure 12.7 


Graphical ver- 
sion of Table 
123 


All of the tables and figures I've shown in the last couple of pages аге the most important calculations in 
ISOH ex. Т hey are the basis for all of the main engine parts. 


COORDINATE SYSTEM 


In the preceding chapter, | briefly touched on how slide maps are structured. N ow you will take that infor- 
mation, add the calculations you did just a few pages ago, and move on to building a primitive version of 
an isometric engine. 


A slide map— just like a rectangular map— consists of a two-dimensional array, usually of some sort of 
structure, but it can be as simple as just an int or a char. Н owever, since you earlier determined that one 
isometric or hexagonal axis has to be diagonal, you have to take that into account for your slide map. 


T heoretically, 32 variations of a slide map are possible. H owever, many of them look quite similar, so only 
four variations have any sort of distinction. T hese four variations are just reflections of the one variation 
that you will use, which is x increasing to the east and y increasing to the southeast, as shown in 

Figure 12.8. 
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Figure 12.8 

X increases to the 
east, and y increas- 
es to the southeast 


N ow that you've covered most of the bases for slide maps, it’s time to start using your knowledge to make 
some practical applications. You will do this by making the main components of ап 150Н ex engine: the 
T ilePlotter, theT ileW alker, and the M ouseM ар. 


TILE PLOTTING 


Although all three components are essential for a proper I SoH ex engine, the first component you will make 
is aT ilePlotter, because you can immediately see the results of your labor with a quick example 


| ve already discussed the axes of a slide map. x increases to the east, and y increases to the southeast. 
Assuming that you plot tile (0,0) at pixel position (0,0), you need to be able to calculate the pixel posi- 
tions of other tiles based on their map coordinates. 


T he first part of the calculation affects the pixel coordinate based on the тар’ x value. Since x increases 
to the east, you can just look at Table 12.2 to see that the map’s x increases the pixel’s x by +Ti 1ewWidth, 
and the тар x does not affect the pixel’s y at all. Н owever, the тар y affects both the pixel’s x and y val- 
ues, by +TileWidth/2 and +TileHei ght/2, respectively. Table 12.4 shows this, and derives the tile plot- 
ting equations. 


Table 12.4 Slide MapTile Plotting 
Pixel Value Increase іп Марх Increase in MapY Equation 


PixelX +TileWidth *TileWidth/2 MapX*TileWidth-MapY* 
TileWidth/2 


PixelY 0 


+ 


TileHeight/2 MapY*TileHeight/2a 
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So, the tile plotting equation, in code form, looks like this: 


//MapX,MapY are map coordinates 
//TileX,TileY are world coordinates 
Ti leX=MapX*TileWidthtMapY*TileWidth/2; 
TileY=MapY*TileHeight/2; 


And, believe it or not, you have aT ilePlotter. Of course, you'd prefer to have a function that plots the tiles 
rather than having to do the equations yourself. T he following is an example of such a function: 


POINT SlideMap_TilePlotter(POINT ptMap,int iTileWidth,int iTileHeight) 
{ 
POINT ptReturn; 
ptReturn.x=ptMap.x*iTileWidth+ptMap.y*iTileWidth/2; 
ptReturn.y-ptMap.y*iTileHeight/2; 
return(ptReturn); 


So youre sitting there screaming, "T hat's it?!” at the top of your lungs. Calm down. A great deal of the 
functionality of ап 150Н ex engine rests on just such a function. 


For hex, there is just a slight modification to the function: 


POINT SlideMap_TilePlotter(POINT ptMap,int iTileWidth,int iHexRowHgt ) 
{ 


POINT ptReturn; 
ptReturn.x=ptMap.x*iTileWidth+ptMap.y*iTileWidth/2; 
ptReturn.y=ptMap.y*iHexRowHat ; 

return(ptReturn) ; 


№ ow that you actually have some code, try an example Load up 150Н ех12 1.срр; it uses the same plot- 
ting function that | showed you earlier. As currently written, it plots ап eight-column by 20-row slide map, 
as shown in Figure 12.9.Т he main work is done by two functions: SetUpMap and DrawMap.T he rest of 
the program is just your basic "set up D irectD raw" type of stuff. 
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Figure 12.9 


The output of example 
IsoHex12_1.cpp 


T he setupMap function (shown next) loops though all the map squares, assigning each square to a random 
tile (| have just a handful of tiles, all the same shape.) N otice that | base the random number on the num- 
ber of tiles in the set. | could add as many tiles as | want and not have to recompile this code. 


void SetUpMap() 
{ 
//randomly set up the map 
for(int x=0;x<MAPWIDTH; х++) 
{ 
for(int y=0;y<MAPHEIGHT;y++) 
{ 
iTileMapL[x]lyJ=rand()%(tsIso.GetTileCount()); 


T he DrawMap function loops through all the map squares and uses the plotter to plot them: 


void DrawMap() 

{ 
POINT ptTile;//tile pixel coordinate 
POINT ptMap;//map coordinate 
//get tile width and height 
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int iTileWidth=tsIso.GetTileList()[0].rcSrc.right- 
tsIso.GetTileList()L[0].rcSrc.left; 
int iTileHeight=tsIso.GetTileList()[0].rcSrc.bottom- 
tsIso.GetTilelList()[0].rcSrc.top; 
//the y loop is outside, because we must blit in horizontal rows 
for(int у=0 ; У<МАРНЕІСНТ; у++) 
{ 


for(int x=0;x<MAPWIDTH;x++) 

{ 
//get pixel coordinate for map position 
ptMap.x=x; 
ptMap.y=y; 
ptTile-SlideMap TilePlotter(ptMap,iTileWidth,iTileHeight); 
//plot the tile 
tsIso.PutTile(lpddsBack,ptTile.x,ptTile.y,iTileMapL[x]Ly1) ; 


} 


N ow you can see one of the major downfalls of the slide тар. I’m sure you noticed that most of the 
screen is blank, and only а portion of the corner is filled in with tiles. T his is the biggest limitation of 
Slide maps. You just cant make a map that fills up the entire screen unless you waste a considerable number 
of tiles doing so. For this reason, slide maps are unsuitable for many types of games. 


Н owever, in games that scroll, you can use slide maps to make the scrolling direction diagonal and give а 
nice illusion of 3D. 


SCROLLING 


| covered the term srollingin Chapter 10, "T ile-Based Fundamentals,’ and mentioned it several times since, 
but | havent yet gone into what is involved. Your next task is to make a larger slide map (still with random 
tiles on it). You will scroll though it using the arrow keys. T his will by no means be an optimized scroll; all 
tiles from thetilemap will be blitted each frame, and you will гау on the clipper to keep them out. 


You will use the entire screen, so the screen space and view space are both (0,0) - (640,480). T his will be 
the window into your little tile world, as shown in Figure 12.10. 
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Figure 12.10 


Screen space/view 
space 


Viewspace (0,0) 


Viewspace (WIDTH,HEIGHT) 
— 


Calculating world space is quite simple. Simply take the world rectangles (which can be retrieved with the 
help of {Пет ilePlotter) and use Uni onRect to combine them all into one big rectangle, as shown in Figure 
12.11. (In your case, you can cheat and just use the upper-right and bottom-left extent to make the world 
space rectangle.) 


Figure 12.11 
World space RECT 


You'll use another type of anchor. Т his time, the anchor matches the screen space/ view space coordinate 
(0,0) with a coordinate in the world space (that coordinate being the contents of the anchor). Т his anchor, 
when used with the output of the plotter, gives you the proper screen coordinate for the tile. Figure 12.12 
shows such an anchor in action. 
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Figure 12.12 


Screen anchor in 
the world space 


Finally, you want to keep the anchor in values that are valid. T hat is, you dont want to allow scrolling too 
far away from the tilemap. So you need to create anchor space, the boundaries that clip the anchor. To do 
so, simply make a rectangle that starts at the upper left of the world space and has a width and height 
equal to the difference of world space width and screen space width. Figure 12.13 shows this idea 
graphically. 


< Figure 12.13 


Screens; Width 
ке Anchor space 


So, with all of this in mind, go back to the task of scrolling. Load up 150Н ex12_2.cpp— your first little 
scrolling demo. For illustration purposes, | made a number of global variables to keep track of the various 
spaces, 


//spaces 

RECT rcWorldSpace;//world space 

RECT rcScreenSpace;//screen space (also, view space) 
RECT rcAnchorSpace;//anchor space 

POINT ptScreenAnchor;//screen anchor 


T hese spaces are set up or calculated within a function called setupspaces. (I'm not one who gives my 
functions incredibly clever names, as you might have noticed!) 


void SetUpSpaces() 

{ 
//set up screen space 
SetRect(&rcScreenSpace,0,0,640,480) ; 
//get a few metrics from the tileset 
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int iTileWidth=tsIso.GetTileList()[0].rcDstExt.right- 
tsIso.GetTileList()[0].rcDstExt.left; 
int iTileHeight=tsIso.GetTileList()[0].rcDstExt.bottom- 
tsIso.GetTileList()[0].rcDstExt.top; 
//grab tile rectangle from tileset 
RECT rcTilel; 
RECT rcTile2; 
POINT ptPlot; 
POINT ptMap; 
//grab tiles from extents 
CopyRect(&rcTilel,&tsIso.GetTilelist()[0].rcDstExt); 
CopyRect(&rcTile2,&tsIso.GetTilelist()[0].rcDstExt) ; 
//move first tile to upper-left position 
ptMap.x-0; 
tMap.y-0; 
tPloteSlideMap TilePlotter(ptMap,iTileWidth,iTileHeight); 
ffsetRect(&rcTilel,ptPlot.x,ptPlot.y); 
/move first tile to lower-right position 
tMap.x=MAPWIDTH-1; 
tMap.y-MAPHEIGHT-1; 
tPloteSlideMap TilePlotter(ptMap,iTileWidth,iTileHeight); 
OffsetRect(&rcTile2,ptPlot.x,ptPlot.y); 
//combine these two tiles into world space 
UnionRect(&rcWorldSpace,&rcTilel,&rcTile2); 
//copy world space to anchor space 
CopyRect(&rcAnchorSpace,&rcWorldSpace); 
//subtract screen space 
//adjust right edge 
rcAnchorSpace.right-=(rcScreenSpace.right-rcScreenSpace. left); 
//make sure right not less than left 
if (rcAnchorSpace.right<rcAnchorSpace. left 
rcAnchorSpace.right=rcAnchorSpace. left; 
//adjust bottom edge 
rcAnchorSpace. bottom-=(rcScreenSpace.bottom-rcScreenSpace. top); 
//make sure bottom not less than top 
if (rcAnchorSpace. bottom<rcAnchorSpace. top 
rcAnchorSpace. bottom=rcAnchorSpace. top; 
//initialize screen anchor 
ptScreenAnchor. x=0; 
ptScreenAnchor. y=0; 
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T his is the longest function in the program, as it should be. All scrolling is based on the calculations here. 
After you have your variables set up, implementing scrolling becomes a simple matter. Т he огаммар func- 
tion is mostly the same as the one you saw іп 150Н ех!) 1.cpp, with a minor change (which | have high- 
lighted in bold) to include the use of the anchor. 


void DrawMap() 
{ 
POINT ptTile;//tile pixel coordinate 
POINT ptMap;//map coordinate 
//get tile width and height 


int iTileWidth=tsIso.GetTileList()[0].rcSrc.right- 
tsIso.GetTileList()[0].rcSrc. left; 

int iTileHeight=tsIso.GetTileList()[0].rcSrc.bottom- 
tsIso.GetTilelist()[0].rcSrc.top; 


//the y loop is outside, because we must blit in horizontal rows 
for(int y=0;y<MAPHEIGHT; y++) 
{ 


for(int x=0;x<MAPWIDTH; х++) 

{ 
//get pixel coordinate for map position 
ptMap.x-x; 
ptMap.y=y; 
ptTile-SlideMap TilePlotter(ptMap,iTileWidth,iTileHeight); 
//plot the tile (adjust for anchor) 
tsIso.PutTile(1lpddsBack, ptTile.x-ptScreenAnchor.x, 

ptTile.y-ptScreenAnchor.y,iTileMap[x]Ly1); 


Finally, to make scrolling work with the arrow keys, | modified Prog Loop to respond to the four arrows: 


//check for keys, and adjust screen anchor 
//up 
if(GetAsyncKeyState(VK UP)«0) 
{ 
if(ptScreenAnchor.y>rcAnchorSpace.top) ptScreenAnchor.y-; 
} 
//down 
if (GetAsyncKeyState(VK_DOWN) <0) 
{ 
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if (ptScreenAnchor.y<rcAnchorSpace.bottom) ptScreenAnchor.y++; 
} 
//right 
if(GetAsyncKeyState(VK RIGHT)«0) 
{ 


if (ptScreenAnchor.x<rcAnchorSpace.right) ptScreenAnchor.x++; 
} 
/flett 
if(GetAsyncKeyState(VK LEFT)«0) 
{ 


if (ptScreenAnchor.x>rcAnchorSpace. left) ptScreenAnchor.x-; 
} 


With all of these working together, you can run the program and move the view around the map with the 
arrow keys. I've talked to a lot of folks about scrolling, and | ve seen some pretty complicated methods of 

doing it— most of them either didn’t work or worked very poorly. T he method | presented here will work 
in all cases. If you want to make a rectangular map that works with aT ilePlotter, it will work. It will also 

work with any of the other types of IsoH ex tilemaps. 


N aturally, you arent totally finished with your treatment of scrolling, but you are finished for now. T he 
method here works, even if it's not the most efficient. D epending on the size of your tilemap, many tiles 
can be blitted but completely clipped out by the clipper. As maps get bigger, it results in more of a per- 
formance hit. You'll return to scrolling and improve on this method in a later chapter. 


TILE WALKING 


T he next fundamental piece of an isometric engine is theT ileW alker. A T ileW alker does nothing more 
than move from one map location to an adjacent map location based on a direction traveled. M uch like 
theT ilePlotter, theT ileWalker is a very easy-to-implement component. 


Figure 12.14 shows the allowable directions of movement for iso and hex tiles. As you can see, iso allows 
eight directions and hex allows six. In a normal rectangular tilemap, tile walking is very easy because of 
how thetiles line up next to one another. Table 12.5 shows how the x and y coordinates change in a rec- 
tangular map. 


Figure 12.14 
Directions of 
movement for iso 
and hex 


Table 12.5 Rectangular Tile Walking 


Change y 
эЛ 


Direction Change x 
North 0 

N ortheast adl: 

East +1 
Southeast +1 

South 0 
Southwest -1 

W est -1 
Northwest -1 


Figure 12.15 shows a graphical representation of Table 12.5. W e used something of aT ileWalker in the 


Reversi example in Chapter 10, "T ile Based Fundamentals,” in the form of the De1tax and Deltay func- 
tions. (Take a look back at IsoH ех10 4.cpp if you want a refresher.) T hat is all aT ileWalker is. 
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Figure 12.15 


A graphical representa- 
tion of Table 12.5 


"Big deal,” you say. Perhaps it's not а big deal, but it is fundamental for making any sort of tile based 
engine work. In an isometric or hexagonal engine, the numbers become a little weird, so having the 
T ileWalker in a nicely wrapped-up function is more important. 


So, with the purpose of aT ileWalker in mind, consider the slide map. From the get-go, you know that x 
increases in the east direction, so for eastward movement, you add 1 to x and leave y alone. Conversely, 
moving west has the opposite effect (subtract 1 from x and leave y alone). Also, you know that moving 
southeast increases y by 1 and leaves x alone, and conversely, moving to the northwest subtracts 1 from y 
and leaves x alone. So far, you have the information shown in Table 12.6. 


Table 12.6 Slide MapTileWalker (So Far) 


Direction Change x Change y 
East +1 0 
Southeast 0 +1 

W est -1 0 


Northwest 0 -1 
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You have four of the eight directions, and you just have to derive the other directions based оп what you 
already have To do this, you simply make movements you know how to make in order to get to squares to 
which you have not yet gone. Take a look at the directions one by one. 


NORTH 


To move north, you can move one square to the east, two squares to the northwest. T he net change for x is 
+ 1(east) +0(northwest)+0(northwest)= +1.Т he net change for y is +0(east) - 1(northwest) - 1(north- 
west)= -2. A graphical representation of this derivation is shown in Figure 12.16. 


Figure 12.16 


Moving north on a 
slide map 


NORTHEAST 


To move northeast, you can move one square to the east and one square to the northwest. T he net change 
for x is + 1(east)+0(northwest)= +1.Т he net change for y is +0(east) - 1(northwest)= - 1. A graphical 
representation of this derivation is shown in Figure 12.17. 


Figure 12.17 


M oving northeast on 
a slide map 
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SOUTH 
To move south, move one step west, two steps southeast. T he net change for x is - 1(west) +0(south- 
east) + 0(southeast)= - 1. T he net change for y is +0(west)+ 1(southeast)+ 1(southeast)= +2. Figure 12.18 


shows this derivation graphically. 


Figure 12.18 


M oving south on a 
slide map 


SOUTHWEST 
To move southwest, move one step west, one step southeast. T he net change for x is - 1(west) + 0(south- 
east)= - 1. T hene change for y is +0(west) + 1(southeast)= +1. Figure 12.19 shows this graphically. 


Figure 12.19 


M oving southwest on 
a slide map 
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Finally, you have enough information to complete your tilewalking table for slide maps. Table 12.7 shows 
the information for moving all directions. For hex maps, eliminate two opposing directions, depending on 
the Пехадоп$ orientation. 


Table 12.7 Slide MapTilewalking (Complete) 


Direction Change x Change y 
North +1 -2 

N ortheast +1 -1 

East +1 0 
Southeast 0 zi 

South -1 +2 
Southwest -1 +1 

W est -1 0 
Northwest 0 -1 


№ ow that you can walk from tile to tile, it is time to construct a suitable function to do so. In order to 
make it all work, you need to set up a few things. T he first is some sort of enumeration for direction con- 
stants: 


enum IsoDirection{ 


SO_NORTH=0, NOTE 
SO_NORTHEAST=1, If you're interested in 
50 EAST-2, hexagonal (I know 

50. SOUTHEAST-3, you're out there—I сап 
SO_SOUTH=4, hear you breathing), you 
SO_SOUTHWEST=5, simply leave out two 
SO_WEST=6, directions from this 


SO_NORTHWEST=7 enumeration and 
; replace 150_ with HEX . 
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After you have the enumeration, you just have to build the function itself. As with theT ilePlotter, you will 
have theT ileW alker use POINTS: 


POINT SlideMap_TileWalker(POINT ptStart, IsoDirection Dir) 
{ 


switch(Dir) 
{ 
case ISO_NORTH: 
{ 
ptStart.x++; 
ptStart.y-=2; 
break; 
case ISO NORTHEAST: 
{ 
ptStart.x++; 
ptStart.y-; 
}break; 
case ISO_EAST: 
{ 
ptStart.x++; 
break; 
case ISO_SOUTHEAST: 
{ 
ptStart.y++; 
break; 
case ISO SOUTH: 
{ 
ptStart.x-; 
ptStart.yt-2; 
}break; 
case ISO_SOUTHWEST: 
{ 
ptStart.x-; 
ptStart.y++; 
break; 
case ISO_WEST: 
{ 
ptStart.x-; 
break; 
case ISO NORTHWEST: 
{ 
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ptStart.y-; 
}break; 


} 
return(ptStart); 
} 


And you've got your T ileW alker, which brings us to example time. Load ир ISoH ex12 3.cpp. M ake sure 
you get both of the bitmaps and other necessary files. T his example takes the previous scrolling example 
(IsoH ех12 2.срр) and puts in пет ileW alker. 


M y basic goals for this example were to move the cursor around the tilemap using the numeric keypad and 
to keep the view centered on the cursor, or as centered as possible T he phrase "as centered as possible" 
might be a little confusing. W hat | mean by this is that when the current position is within the central part 
of the map, the cursor appears at the center of the screen. W hen the cursor is near the edges, it wont 
appear at the center of the screen (the anchor will remain bound by anchor space). 


Figure 12.20 shows a centered cursor (it's somewhere in the middle of thetilemap). Figure 12.2 1 shows it 
on an edge (the cursor isnt centered). T hese figures demonstrate just how useful an anchor space can be. 

T here are no special cases involved, just the adjustment of ptscreenAnchor to lie within the bounds of 
rcAnchorSpace. 


>< >< >< Figure 12.20 
е à IsoHex12 3 іп the mid- 
dle of the tilemap 


The cursor is in the 
center of the screen. 


ы A, 
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Figure 12.21 


IsoH ех12_ 3 near the 
upper-left corner of 
the map 


The cursor is not 
centered. 


THE CODE FOR 1S0HEXIL_ << 


You've already seen theT ileW alker, and the enum for directions, so | wont repeat those here. T he main 
changes from 150Н ex12 2 to [50Н ex12 3 are the addition of the cursor and the response of numeric 


keypad keys. 


SHOWING THE CURSOR 


T he cursor is shown by calling ShowlsoCursor. T he cursor itself is contained in а tileset (separate from 
the tiles that comprise the map) called tscursor.T he map position of the cursor is contained in the 
global variable ptCursor. 


void ShowIsoCursor() 
{ 

//copy cursor position 

POINT ptMap=ptCursor; 

//get a few metrics from the tileset 

int iTileWidth=tsIso.GetTileList()[0].rcDstExt.right- 
tsIso.GetTileList()[OJ].rcDstExt.left; 

int iTileHeight=tsIso.GetTileList()[0].rcDstExt.bottom- 
tsIso.GetTileList()[0].rcDstExt.top; 

//plot cursor position 

POINT ptPlot-SlideMap TilePlotter(ptMap,iTileWidth,iTileHeight); 

//put the cursor image 
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tsCursor.PutTile(lpddsBack,ptPlot.x-ptScreenAnchor.x,ptPlot.y- 
ptScreenAnchor.y,0); 
} 


ShowIsoCursor performs two major tasks. First, it finds where the cursor is supposed to go using the 
T ilePlotter, and then it puts in the tile, adjusting for the screen anchor. 


MOVING THE CURSOR 


T his is where theT ileW alker comes into play. D uring the program's response to wM_KEY DOWN events, the 
following has been added: 


//move cursor 

if (wParam== UMPAD8) 
oveCursor(ISO NORTH); 
if(wParam-- UMPAD?9) 
oveCursor(ISO NORTHEAST); 
if(wParam-- UMPAD6) 
oveCursor(ISO EAST); 
if (wParam== UMPAD3) 
veCursor(ISO SOUTHEAST) ; 
== UMPAD2) 
veCursor(ISO, SOUTH) ; 


o 
if(wParam 
0 
if (wParam== UMPAD1) 
0 
Й 
o 


veCursor(ISO SOUTHWEST); 
== UMPAD4 ) 
veCursor(ISO_WEST); 
if (wParam==VK_NUMPAD7 ) 


oveCursor(ISO_NORTHWEST) ; 


if(wPara 


Each key on the numeric keypad sends a command to the MoveCursor function, shown next. T he 
MoveCursor function works in two phases. First, it tilewalks the cursor to a new position (it first checks to 
see that the move is valid). Second, it adjusts the anchor and clips the anchor to anchor space. 


void MoveCursor(IsoDirection Dir) 
{ 

//move the cursor using the tilewalker 

POINT ptTemp=SlideMap_TileWalker(ptCursor,Dir); 

//get a few metrics from the tileset 

int iTileWidth=tsIso.GetTileList()[0].rcDstExt.right- 
tsIso.GetTileList()[0].rcDstExt.left; 
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int iTileHeight=tsIso.GetTileList()[0].rcDstExt.bottom- 
tsIso.GetTileList()[0].rcDstExt.top; 

//bounds checking 

//х<0 
if(ptTemp.x«0) ptTemp=ptCursor; 
//y<0 
if(ptTemp.y«0) ptTemp=ptCursor; 
//х>МАРМТОТН-1 
if(ptTemp.x>(MAPWIDTH-1)) ptTemp=ptCursor; 
//y>MAPHEIGHT-1 
if (ptTemp.y>(MAPHEIGHT-1)) ptTemp=ptCursor; 
//assign new cursor position 
ptCursor-ptTemp; 
//do a test plot of the cursor (for centering) 
POINT ptPlot-SlideMap TilePlotter(ptCursor,iTileWidth,iTileHeight); 
/ [center 
ptScreenAnchor.x=ptPlot.x-320+iTileWidth/2; 
ptScreenAnchor.y=ptPlot.y-240+iTileHeight/2; 
//bounds checking for anchor 
if (ptScreenAnchor.x<rcAnchorSpace. left) 
ptScreenAnchor.x=rcAnchorSpace. left; 
F(ptScreenAnchor.y&rcAnchorSpace.top) ptScreenAnchor.y=rcAnchorSpace. top; 
if (ptScreenAnchor.x>rcAnchorSpace.right) 
ptScreenAnchor.x=rcAnchorSpace.right; 
if (ptScreenAnchor.y>rcAnchorSpace. bottom) 
ptScreenAnchor.y=rcAnchorSpace.bottom; 
} 


I 


= 


You may have a question about the centering segment, where | subtract 320 from the anchor x and 240 

from anchor's y, while adding half of the tiles width and height to x and y, respectively. T he 320 and 240 
are easy to explain away— they are half of the width and height of the screen. T hetiles width and height 
modifications are because your tile anchors exist in the upper-left corner of the tile and you must further 
adjust so that the cursor appears in the center of the screen. Later, а C1ipScreenAnchor function will do 
this for you. 


T hat's about all there is to theT ileWalker. Just like {пет ilePlotter, it's a pretty simple concept. T he 
T ileWalker winds up an important part of the M ouseM ap, which you will get to next. 
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T he final core component of any isometric engine is the M ouseM ap. A M ouseM ap is used to convert 
world coordinates into map coordinates. Since the screen anchor lets you easily convert screen coordinates 
into world coordinates, the M ouseM ap is essential for finding out what tile the mouse or other pointing 
device is on (hence the name "M ouseM ap"). It has other uses as well, like streamlining which tiles must be 
blitted to fill up screen space without wasting too many trivially clipped tiles. 


Determining on which tile the mouse rests is the most common dilemma for a lot of folks just beginning 
in ISOH ex. T he overlap makes it confusing, and I ve seen plenty of ways to do it, including some requiring 
hard-to-understand equations. M ouseM aps, once you have the basic idea down, are quite easy, and very 
effective. As you know, determining whether a point is within a ВЕСТ is quite easy— just use the 
PtInRect function! You could come up with many schemes for detecting whether a point is within a dia- 
mond or a hexagon. You might make polygon rans and use Pt InkRgn; this is a valid way to do it, and it 
would work. T he problem is that this method would be slow, since when a region is created, it rips it into 
little rectangles and compares the ротмт to all those rectangles to see if it is within the Ran. 


Alternately, you can use the fact that determining whether a point is within a ВЕСТ is fast. You can divide 
your 150Н ex maps into rectangular areas (as shown in Figures 12.22 and 12.23) and work from there. 

T hese rectangular areas reach from the top of onetile down to thetop of thetileto the south, and from 
the left of the tile to the left of the tile to the east. 


Figure 12.22 


An iso map divided into 
rectangular zones 
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L^ —L- -] Figure 12.23 
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If you take just one of these rectangular areas and color each tile that has a portion within this area with a 


different color (as shown in Figures 12.24 and 12.25), you will have a M ouseM ap. N ow you can do some 
serious work. R eady for the mental leap? 


Figure 12.24 
Iso M ouseM ap 
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Figure 12.25 


Hex M ouseM ap 


NOTE 
Because you have divided your tilemap into rectangular areas, you In reality, you don't want to 
can easily determine which rectangle you are in. After you know leave your MouseMap as a 
which rectangle you are in, you can calculate where you are with- bitmap, because you would 
in that rectangle. If you check the color at that position, you then have to use GDI to get 
know which tile you are on. the pixel color. Later, you will 
create an array, scan the 
bitmap for the different col- 
стеЕР-Жү-ШТЕР ors, and just have numbers іп 
MousEMAPPING scan СЄ UE НЕ ятар 
А А А | example is much better for 
T his section goes through the entire process of mousemapping visualization. 


as it is usually performed— to take the position of the mouse 
and convert it into map coordinates. You start with a ротмт called 
ptMouse, which contains the screen coordinates of the mouse. 
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ЕТЕР НІ CONVERT SCREEN COORDINATES TO 
WORLD COORDINATES 


T his is asimple- enough step. Add the screen anchor to ptMouse. 


//screen to world translation 
ptMouse.x+=ptScreenAnchor.x; 
ptMouse.y+=ptScreenAnchor.y 


ETEPF НЕГІ: SUBTRACT WORLD COORDINATES FOR THE 
UPPER LEFT OF THE MAP Равтттам (O,0) 


For this, you use theT ilePlotter and make use of the tile extent for tile (0,0). In this case, the coordinate 
winds up being (0,0), but in cases where world space extends beyond the tilenap, or when tile anchors are 
not at the upper left of the tile this becomes important. 


//retrieve some tile metrics 

int iTileWidth=tsIso.GetTileList()[0].rcDstExt.right- 
tsIso.GetTileList()[O].rcDstExt.left; 

int iTileHeight=tsIso.GetTileList()[0].rcDstExt.bottom- 
tsIso.GetTileList()[0].rcDstExt.top; 

//get map position 0,0 

POINT ptMap; 

ptMap.x-0; 

ptMap.y=0; 

//determine plot position 

POINT ptPlot=SlideMap_TilePlotter(ptMap,iTileWidth,iTileHeight); 
//adjust the plotted point for the tile’s extent 
ptPlot.xt=tsIso. GetTileList()[0].rcDstExt. left; 
ptPlot.y*-tsIso. GetTileList()[0].rcDstExt.top; 
//subtract ptPlot from ptMouse 

ptMouse.x-=ptPlot.x; 

ptMouse.y-=ptPlot.y; 


N ow ptMouse contains a coordinate relative to the upper left of the tile at map position (0,0).T his is 
important, because the M ouseM ap is designed to be aligned with that tile 
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STEP #5: DETERMINE MOuUSENMAP COORDINATES 

№ ow determine which rectangular area (which is the same size as the М ouseM ap) you're іп by dividing 
ptMouse by the width and height of the M ouseM ap (which would be stored in global variables prior to 
using the М ouseM ap). T hese are the “coarse” М ouseM ap coordinates. 


At the same time, you want to know where within the rectangular area ptMouse points. You will use the 
modulus operator (%) to get the remainder of the division. Т hese are the "fine" M ouseM ap coordinates. 


//find coarse coordinates 

POINT ptMouseMapCoarse; 
ptMouseMapCoarse.x=ptMouse.x/MouseMapWidth; 
ptMouseMapCoarse.y-ptMouse.y/MouseMapHeight ; 
//find fine coordinates 

POINT ptMouseMapFine; 
ptMouseMapFine.x=ptMouse.x%4MouseMapWidth; 
ptMouseMapFine. y=ptMouse.y4MouseMapHeight; 
//adjust for negative fine coordinates 

if (ptMouseMapFine. x<0) 

{ 


ptMouseMapFine.x+=MouseMapWidth:; 
ptMouseMapCoarse.x-; 
} 
if (ptMouseMapFine. y<0) 
{ 


ptMouseMapFine. y+=MouseMapHeight; 
ptMouseMapCoarse.y-; 


} 


Some explanation might be necessary for the segment on adjusting for negative fine coordinates. In slide 
maps, this adjustment is unnecessary, because all plotted tiles have a nonnegative coordinate for their 
upper-left corner. Later, when we get into diamond maps, this adjustment becomes necessary. | just wanted 
to bring it up here so that all the parts of mousemapping are explained in one spot. 


Because of the way computers do integer arithmetic, using division on a negative number works differently 
than it does in mathematics. In mathematics, - 32/ 64 would be - 1 (the nearest integer bdow the actual 
answer). [п a computer, however, - 32/ 64 is 0 (the nearest integer closest to 0). 


T he modulus operator (%) is based on division. T he calculation looks something like this: 


Remainder=Dividend - [Dividend/Divisor] * Divisor 
T he [] means integer result. 


In mathematics, the modulus always gives you a positive value. Take, for example, (-32)%64 and 32% 64. 
(T he first number is the dividend, and the second is the divisor.) 
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COMPUTER 
Remainder = - 32- [- 32/ 64]*64=- 32-0*64=- 32-0=- 32 
Remainder = 32-[32/ 64]*64=32-0*64=32-0=32 


MATHEMATICS 

Remainder = - 32-[-32/ 64]*64z - 32-(-1)*64=-32+64=32 

Remainder = 32-[32/ 64]*64=32+(0)*64=32+0=32 
As you can see, mathematics always gives a nonnegative result, but with a computer, it depends. Luckily, 
computers do have the nice even steps, as long as the dividend and divisor are both positive. 


So, when you come to a negative renainder on a computer, you simply add the divisor to it, subtract 1 
from the calculated answer, and you're good to go. Pesky integer arithmetic will bother you no more. 


ПАТЕР #1] PERFORM A COARSE TILE WALK 


N ow you get to incorporate theT ileW alker; both steps 4 and 
5 make use of it. T he first task is a coarse tile walk based on NOTE 
the ptMouseMapCoarse X and y. If ptMouseMap.x IS greater 


than 0, take that many steps to the east. If x is negative, take Hey hex folks. No, 1 haven't for- 
that many steps to the west. M ake similar north or south доңуп you. You might. 
steps for negative or positive y values, sir lols eral КИЕ 

| coarse tile walk, because two of 
A coarse tile walk looks something like this: your directions don't exist.T hey 
//set up map coordinate are usually north and south or 
ВМВ: east and west.As applicable, you 
В have to make double steps, like а 


northeast step plus a southeast 
step to make one eastward step 
if you сап“ go east. 


//north movement 
whi le(ptMouseMapCoarse. y<0) 
{ 
ptMap-SlideMap TileWalker(ptMap,ISO NORTH); 
ptMouseMapCoarse.yt+; 


} 
//south movement 
while(ptMouseMapCoarse.y»0) 
{ 
ptMap-SlideMap TileWalker(ptMap,ISO SOUTH); 
ptMouseMapCoarse.y-; 


} 

//east movement 

whi le(ptMouseMapCoarse. x<0) 
{ 
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ptMap-SlideMap TileWalker(ptMap,ISO WEST); 
ptMouseMapCoarse. x++; 

} 

//west movement 

while(ptMouseMapCoarse.x>0) 

{ 


ptMap-SlideMap TileWalker(ptMap,ISO EAST); 
ptMouseMapCoarse.x-; 


N ow you are pretty close to your real map coordinate— no more than a single tile away. 


ТЕР FSi USE THE MoOusEeNIAP LOOKUP TmHELE 


T his is where the M ouseM ap comes in. Check the color of the map (or the value in the lookup table) 
corresponding to the coordinate within ptMouseMapFine.T his will contain one of five values: MM. CENTER, 
MM NW, MM NE, MM SE, Or MM Sw. Each value tells you how to make your final tile walk onto the proper map 
position (MM CENTER simply means no tile walk is necessary). For the purpose of illustration, you will 
make your M ouseM ap a 2D array of values. 


//use mousemap lookup table 

switch(MouseMapLookUp[ptMouseMapFine.x][ptMouseMapFine.y]) 

{ 

case MM_CENTER: 
{ 


//no movement 
}break; 
case ММ МЕ: 
{ 


//move one to the northeast 
ptMap-SlideMap TileWalker(ptMap,ISO NORTHEAST) ; 
}break; 
case MM_SE: 
{ 


//move one to the southeast 
ptMap=SlideMap_TileWalker(ptMap, ISO_SOUTHEAST) ; 
}break; 
case MM_SW: 
{ 
//move one to the southwest 
ptMap=SlideMap_TileWalker(ptMap, ISO_SOUTHWEST) ; 
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ibreak; 
case MM NW: 
{ 


//move one to the northwest 
ptMap=SlideMap_TileWalker(ptMap, ISO_NORTHWEST) ; 
break; 


And youre done! T he coordinate in ptMap is the map coordinate the mouse points to. Easy, right? | know 
it seems like a lot of code, but it's quite fast. 


N ow that you've got the basic algorithm down, you just need to wrap it. T he first thing you need is a nice 
little structure to hold the lookup table and M ouseM ap dimensions (width and height). | suggest some 
thing like the following: 


//enumeration type for mousemap directions 

enum MouseMapDirection (MM CENTER,MM NE,MM SE,MM SW,MM NWj; 
struct CMouseMap 

{ 


//x and y size of the mousemap 


POINT ptSize; 
//reference point for overlaying the mousemap on tile 0,0 
POINT ptRef; 


// lookup array 
MouseMapDirection* mmdLookUp; 


T he ptMouseMapSize member contains the width in x and the height in y. T he world coordinate for tile 

(0,0) is stored in ptMouseMapRef. (T his means you only have to calculate it once and can thereafter use it 
many times.) chMouseMapLookUp is a pointer that you allocate to store enough information for the entire 
map. It is a one-dimensional array that acts like a two-dimensional array. 


N ext, you need a function that loads in a M ouseM ap from a bitmap. To make it happen, use cGDICanvas: 


void MouseMapLoad(CMouseMap* pmm,LPCTSTR lpszfilename) 
{ 

//create canvas 

CGDICanvas gdic; 

// load file 

gdic.Load(NULL,1pszfilename) ; 

//assign width/height 
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pmm->ptSize.x=gdic.GetWidth(); 
pmm->ptSize.y=gdic.GetHeight(); 

//allocate space for the lookup table 

pmm-»mmdLookUp- new 
MouseMapDirection[gdic.GetWidth()*gdic.GetHeight()]; 
//colorref values for filling lookup 

COLORREF crNW-GetPixel(gdic,0,0); 

COLORREF crNE=GetPixel(gdic,gdic.GetWidth()-1,0); 

COLORREF crSW=GetPixel(gdic,0,gdic.GetHeight()-1); 
COLORREF crSE=GetPixel(gdic,gdic.GetWidth()-1, gdic.GetHeight()-1); 
//test pixel color 

COLORREF crTest; 

//scan convert bitmap into lookup values 

for(int y=0;y<gdic.GetHeight();yt++) 

{ 


for(int x=0;x<gdic.GetWidth();x++) 
{ 


//grab test pixel 
crTesteGetPixel(gdic,x,y); 

//set lookup to default 
pmm-»mmdLookUp[x*y*pmm-»ptSize.x]-MM CENTER; 
//check colors 

if(crTest==crNw) 
pmm-»mmdLookUp[x-y*pmm-»ptSize.x]-MM NW; 
if(crTest==crNE) 
pmm-»mmdLookUp[x-y*pmm-»ptSize.x]-MM NE; 
if(crTest==crSw) 
pmm-»mmdLookUp[x-y*pmm-»ptSize.x]-MM SW; 
if(crTest--crSE) 
pmm-»mmdLookUp[x-y*pmm-»ptSize.x]-MM SE; 
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T his function does all the work to get a bitmap converted to a lookup table Н owever, it doesnt put in the 
reference point for tile (0,0). Also, the lookup table was dynamically allocated, so to avoid memory leakage 
it will have to be deallocated later with the following line: 


//mm is a CMouseMap variable 
delete [] mm->mmdLookUp; 


A NYIOUSEMAPPFPING EXAMPLE 


N ow you have all you need to implement а М ouseM ap in an IsoH ex application. Load IsoH ех!) 4.срр. 
T his example is based on IsoH ex12_3.cpp, but instead of keyboard control, you now have mouse control. 
T he M ouseM ap setup and M ouseM ap functions are essentially the same as the code | showed you earlier, 
with the exception that now the tile (0,0) reference point is stored in the M ouseM ap structure and does 
not have to be calculated each time. Another difference (albeit a small one) is that all 

of the lines where irilewidth and iTi1eHeight were calculated are gone; I'll talk more about that a 
little later. 


О пе more enhancement | put into this example is scrolling by moving the mouse pointer near the edge of 
a screen. T he closer it gets, the faster the scroll. T he amount of scrolling is stored in a variable called 
ptScreenAnchorScro11 (a РОТ\Т). Т he following is the snippet that does the scrolling itself: 


//scroll the map 
ptScreenAnchor.x+=ptScreenAnchorScroll.x; 
ptScreenAnchor.y+=ptScreenAnchorScroll.y; 
ClipScreenAnchor(); 


T he ClipScreenAnchor function (shown next) simply ensures that the screen anchor doesnt wander out 
of anchor space it's similar to what you did when you centered the cursor іп IsoH ех12 3.срр. 


void ClipScreenAnchor() 
{ 

//clip to left 
if (ptScreenAnchor.x<rcAnchorSpace. left) 
ptScreenAnchor.x=rcAnchorSpace. left; 

//clip to top 

if (ptScreenAnchor.y<rcAnchorSpace.top) ptScreenAnchor.y=rcAnchorSpace.top; 
//clip to right 

if (ptScreenAnchor.x>rcAnchorSpace.right) 
ptScreenAnchor.x=rcAnchorSpace.right; 

//clip to bottom 
if (ptScreenAnchor.y>rcAnchorSpace. bottom) 
ptScreenAnchor.y=rcAnchorSpace.bottom; 


} 
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T his is a very simple but very effective scrolling scheme. It would not be possible without a screen anchor 
and anchor space rectangle. As you might have guessed, you can use this exact scrolling algorithm in any of 
your 150Н ex games and demos. It just goes to show that you dont need especially complicated code to 
allow scrolling. 


T he main work of this example is done in the им_моузЕмомЕ handler. T he tasks are divided into three 
parts: mousemapping the cursor, clipping the cursor to a valid tile (that is, not allowing cursor locations 
outside the tilemap), and assigning the values of ptScreenAnchorScro11 if the mouse is near one or 
more of the screen's edges. 


case WM MOUSEMOVE: 
{ 


//grab mouse coordinate 

POINT ptMouse; 

ptMouse.x=LOWORD(1Param) ; 

ptMouse. у=НІМОКО (1 Param) ; 

//mousemap the mouse coordinates 

ptCursor-SlideMap MouseMapper(ptMouse,&mmMouseMap) ; 
//clip cursor to tilemap 

if(ptCursor.x«0) ptCursor.x=0; 

if(ptCursor.y«0) ptCursor.y=0; 
if(ptCursor.x>MAPWIDTH-1) ptCursor.x=MAPWIDTH-1; 
if(ptCursor.y»MAPHEIGHT-1) ptCursor.y=MAPHEIGHT-1; 
//check for scrolling zones 
ptScreenAnchorScroll.x-0; 

ptScreenAnchorScroll.y=0; 

//top 
if (ptMouse.y<8) 
ptScreenAnchorScroll.y=-(8-ptMouse.y); 


//bottom 
if (ptMouse.y>472) 
ptScreenAnchorScroll.y=(ptMouse.y-472); 


//left 
if(ptMouse.x«8) 
tScreenAnchorScroll.xe-(8-ptMouse.x); 


oO 


//right 

if (ptMouse.x>632) 

ptScreenAnchorScroll.xe(ptMouse.x-632); 
return(0); 

}break; 
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Figure 12.26 shows the output of IsoH ex12_4.cpp. It looks quite a bit like the other examples in this 
chapter, except that the highlighted tile contains the mouse. 


Figure 12.26 
Output of IsoHex12 4.cpp 


The mouse is contained in 
this tile. 


C А». > 


As youve been going along here, you've probably noticed that you're are getting further and further away 
from code that actually manipulates the етар and the coordinates of the various tiles. M ойу, you rely 
on the three major iso components— theT ilePlotter, theT ileW alker, and the М ouseM ap. T his is a good 
thing, because it frees you from special case code and from having to always think about the coordinate 
system while trying to add other features to your games. 

T hat's it for mousemapping for now. You'll learn more about it later, when | will show you some extra and 
surprising uses of the М ouseM ap. Your fundamental slide map iso engine is complete, and the possibilities 
are now endless. 
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SUMMARY 


You've come quite a way from the rectangular tiles and tilemaps discussed in Chapter 10. | showed you 
that isometric tile based algorithms are not nearly as complex as you might have thought. [п fact, with the 
steps you've taken in this chapter, you might now think they're downright simple. Youd be right! 


Also, the topic of scrolling, which befuddles and confuses most 150Н ex beginners, has been demystified 
with the use of anchors and anchor space. You arent done yet with scrolling. Later, you will make it more 
efficient, but the basic foundation is there. 


You've got the goods on slide maps, which are great to bring out first because of their simpler structure, 
but we still have two more map types to discuss. Н owever, dont discount the usefulness of slide maps. 
T he very first isometric game that | know of (Zaxxon, Sega 1982) used something very similar to an iso 
slide map. 


Also, you took a brief look at hex in this chapter, mainly to show you how similar iso and hex are. From 
here on out, however, you'll concentrate on iso. For the topics and specific concerns of hexagonal tile map- 
ping, check out Appendix B, “H exagonal T ile Based G ames.” 


Staggered maps, here we come! 
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he preceding chapter covered the basic groundwork for 

isometric engines while exploring the simplest of the iso 
tilemap types, the slide map. T heres not much call for slide 
maps in computer games, but if you're creative enough, you can 
find a use for them. 


T his chapter focuses on one of the more commonly used map 


types— the staggered map. M any strategy games, past and pres- 


ent, use this type of map, games such as C ivilization 11, 
Civilization: Call to Power, Imperialism 11, and Alpha C entauri, T hese 
are (or were) popular titles. (Civ 11, several years old, does not 
show its age; its popularity continues. It is possibly one of the 
most heavily played strategy computer games ever.) 


COORDINATE GYSTEM 


Figure 13.1 is a graphical representation of a staggered етар. T he x-axis increases to the east, just as it 
does in slide maps. T he unusual part is the y-axis, which alternately moves southeast and southwest, 


NOTE 


Be aware: Most of the funda- 
mentals for IsoHex maps were 
covered in Chapter 12, "Slide 
Isometric Tilemaps.” You might 
want to turn back at times for a 
quick refresher.T his chapter is 
considerably shorter than 
Chapter 12, since in it | cover 
just algorithms specific to the 
staggered tilemaps. 


depending on what tile row you are on, giving a somewhat zigzagging southern direction to the y-axis. T he 
advantage of this is that you can more easily fill rectangular areas without encountering some of the diffi- 


culties you had with slide maps. 


Figure 13.1 


Staggered tilemap 
coordinate system 
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T he best way to describe the coordinate system for staggered maps is not to speak of the strange behavior 
of the y-axis, but instead to say that even rows (y=0, 2, 4, and so on) are in a straight column, and odd 
rows (у= 1, 3, 5, and so on) are shifted to the east by half a tile Of course, you can shift to the west if 
you like, or you can even turn the map on its side and offset vertically instead of horizontally, but the 
examples in this chapter use the even/ odd row scheme to plot your tiles. 


Because of this different coordinate system, you will find some differences in theT ilePlotter and 
T ileWalker (especially {Пет ileW alker). H owever, as you will see, the M ouseM ap is completely unaffected, 
because it relies on the other two components to work properly. 


TILEFLOTTING 


№ aturally, you will want to plot your staggered maps in horizontal rows, just as you did with your slide 
maps. T his is easy to do because of the eastward direction of the x-axis. T he y-axis may trip you up, but 
only a little. 


At first glance, you might consider special cases for your T ilePlotter, including a simple check to see if y is 
odd or even, as shown here: 


//check for even y 
if (y%2==0) 
{ 
//even 
//special case for even tiles here 


//odd 
//special case for odd tiles 
} 


T his is a valid way to go about solving the problem, but I’m not particularly thrilled with it. T he problem 
| have is that it includes special-case code, and experience has shown me that special-case code tends to 
break easier. Ideally, | would have a nice equation that works for all cases. Fortunately, | have one. 


Besides checking y%2 for an odd/ even test, you can alternately use y&1. For all even numbers, y&1 will 
yidd 0, and for all odd numbers, y&1 will yield 1. So, problem solved. 


N ow consider the coordinate system and well come up with some nice equations to use in your 
T ileP lotter. T he x-axis moves in the east direction, so here's a portion of your equation for plotting x: 


//MapX is map coordinate, PlotX is world coordinate 
PlotX-MapX*TileWidth; 
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T hat's not the end of the story, however. T he odd rows (where y&1 yields 1) are shifted east by half a tile 
(+TileWidth/2), so you modify the equation slightly: 


//mapx, mapy are map coordinates, plotx is world coordinate 
PlotX=MapX*TileWidth+(MapY&l)*(TileWidth/2); 


T he y-coordinate calculation is much simpler. Т he y-axis alternately moves southeast and southwest. Both 
of these directions affect the world y-coordinates by moving half of a Ti1eHeight downward. So, the cal- 
culation for y is as follows: 


//mapy 15 а map coordinate, ploty is а world coordinate 
PlotY=MapY*(TileHeight/2); 


And that's all there is to it! You just take these two calculations, slap them into a function, and youre off: 


POINT StagMap_TilePlotter(POINT ptMap,int iTileWidth,int iTileHeight) 
{ 
POINT ptPlot; 
ptPlot.x=ptMap.x*iTileWidth+(ptMap.y & 1) * (iTileWidth/2); 
ptPlot.y=ptMap.y*(iTileHeight/2); 
return(ptPlot); 
} 


| bet youd like an example, wouldn't you? Very well. Load ир IsoH ех13 1.cpp. T he code suspiciously 
resembles that of |soH ех12 1.срр, as well it should, since! copied the code into a new workspace, made 
about five minor changes, and recompiled it. Talk about a short development cycle! 


Figure 13.2 shows the result of running [50Н ex13 1.срр. It is essentially the same code as in the preced- 
ing chapter, but with a drastically different look. T he staggered map takes up more of a rectangular area, 
and if you can dip out the jagged edges, it fills up a rectangular viewport very nicely. T his is a lot better 
result than you can achieve with a slide map, which tends to have large, ugly black areas. 
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Figure 13.2 
Output of IsoHex13 1.cpp 


It’s astounding, really, that after exploring the basics so much in the last chapter, staggered maps are a 
breeze to learn. T heT ileP lotter is built, and you are one-third of the way to mastering the subtleties of 
staggered maps. 


TILEWALKING 


T he staggered map T ileW alker will put to rest a few questions you might have had in Chapter 12. If you 
didnt immediately pick up on something a little strange with the slide map T ileW alker, let me point it out. 


As you recall, the slide map T ileW alker looks like the following: 


POINT SlideMap TileWalker(POINT ptStart, IsoDirection Dir) 
{ 
//depending on direction, move the point 
switch(Dir) 
{ 
case ISO_NORTH: 
{ 
ptStart.x++; 
ptStart.y-=2; 
}break; 
case ISO_NORTHEAST: 
{ 
ptStart.x++; 
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ptStart.y-; 
}break; 
case ISO_EAST: 
{ 


ptStart.x++; 
}break; 
case ISO SOUTHEAST: 
{ 
ptStart.yt++; 
}break; 
case ISO SOUTH: 
{ 
ptStart.x-; 
ptStart.yt=2; 
}break; 
case ISO SOUTHWEST: 
{ 
ptStart.x-; 
ptStart.yt++; 
}break; 
case ISO WEST: 
{ 


ptStart.x-; 
}break; 
case ISO_NORTHWEST: 
{ 
ptStart.y-; 
}break; 
} 
//return the point 
return(ptStart) ; 


} 


Still cant see it?T ime ир!Т he problem with the slide map T ileW alker is that it can take only a single step 
at atime. T his seems silly, considering the regularity of the slide map, and it reduces the efficiency of the 
M ouseM ap, which uses theT ileWalker to convert from M ouseM ap coordinates to map coordinates. 


W hy would 1 intentionally write inefficient code? Well it's not teribly inefficient. Incrementing and decre 
menting variables and passing eight bytes back from a function hardly affects anything, especially in simple 
examples like the ones you've been doing (rest assured that you'll have much better T ileW alkers later). 
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So, | should have designed the slide map T ileW alker according to how many steps you need to go in the 
given direction. Т he prototype would look something like this. 


POINT SlideMap_TileWalker(POINT ptStart, IsoDirection Dir, int iSteps); 


T here are two reasons | didnt do this from the start. О ne, these examples are meant to educate, and being 
as efficient as possible isn't necessarily the best way to go about explaining something. Two, | wanted to 
have uniformity while explaining the three map types, and in staggered maps, tilewalking in multiple steps 
is more difficult. 


W hat do | mean?W all, consider Figure 13.3, which illustrates two steps, both in the southeast direction, 
starting from map position (0,0). T he first step moves from (0,0) to (0,1). T he second step moves from 
(0,1) to (1,2). Take a closer look at these steps. 


Figure 13.3 


The TileW alker 
problem with 
staggered maps 


Step 1: 

Stat x=0 y=0 

End x=0 у-1 
Difference dx=0 dy=1 
Step 2: 


Stat x=0 y=1 
End x=1 у-2 
Difference dx=1 dy=1 


As you can plainly see, the differences in these two steps change from one step to another. Both steps have 
ay difference of 1, but the x differences change between steps. T his shows that multi-step tilewalking can 
be solved, with some difficulty. I’m not saying it's impossible, but the code is a bit confusing until you've 
got a solid grasp of what's going on. So, for now, at least, stick with single-step tilewalking. 


For your staggered map T ileW alker, you'll treat map coordinates as two special cases— one for an even y- 
coordinate, and one for an odd y-coordinate You will later put them together in a single function. 
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M oving east or west is the same, no matter if y is odd or even. M oving east causes x to increase by 1, and 
moving west causes x to decrease by 1.T hey is unaffected in ether case. 


Direction Change x Change y 


East 1 0 

West -1 0 

From an even y-coordinate, y increases to the southeast. From an odd y-coordinate, y increases to the 
southwest. 

Direction yEven/Odd Change х Change y 

Southeast Even 0 1 

Southwest Odd 0 1 


Believe it or not, you now have enough information to derive the rest of the values for your T ileW alker. I'll 
go over all of it, step by step, so that you can have a full understanding of how it works (it can seem really 
strange at first). 


First, since you move x by 0 and y by 1 to move southeast from an even y position (which then leaves you 
at an odd y position), the opposite move (moving northwest from an odd y position) should change x by 
0 and y by - 1. Similarly, since moving from an odd y increases y to the southwest, moving northeast from 
an even y should change y by - 1. Figure 13.4 demonstrates what I'm trying to say— in this case, words 

dont convey the idea nearly as well as a figure does. T he directions you have so far are listed in Table 13.1. 


Figure 13.4 


Deriving the staggered 
TileW alker 
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Table 13.1 StaggeredTileWalker (Initial) 
Direction  4/-x(Eveny) +-у (Емеп у) +-х (Oddy) -y (Odd у) 


North 7? 7 7 7 
Northeast 0 -1 7? 7? 
East 1 0 1 0 
Southeast 0 1 7? 7? 
South 7 7 7 7 
Southwest 7 7? 0 1 
W est 1 0 1 0 
Northwest 7 7 0 -1 


From this, you can easily derive the rest. Do them one at a time, starting with the even y directions. 


EVEN Y TILEWALKING 
You are missing four directions: north, south, southwest, and northwest. 


To move northwest, you can first move northeast and then move west. M oving northeast subtracts 1 from 
y (leaving you at an odd y position). M oving west subtracts 1 from x whether y is odd or even. So, moving 
northwest moves you to (x- 1,у- 1) if you start on an even y-coordinate. 


To move southwest, you first move southeast to (х,у+ 1), an odd y-coordinate. From there, you move west 
by subtracting 1 from x, leaving you at (x- 1,y+1). 


To move north, you first move northeast to (x,y- 1), an odd y-coordinate. N ext, you move northwest, 
which subtracts 1 from у since you are on an odd у, giving you (ху-2). То move south, you move south- 
east to (ху+1) (odd), and then southwest to (x,y+2). Your even y T ileWalker is complete, as shown in 
Table 132. 
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Table 13.2 Staggered TileWalker (Completed Even) 
Direction -x (Even y) +-у (Even у) +-х (Оу)  +-y (Odd y) 


North 0 -2 т 7? 
N ortheast 0 -1 т 7? 
East 1 0 1 0 
Southeast 0 1 7? 7? 
South 0 2 7 7 
Southwest -1 1 0 1 
W est 1 0 1 0 
Northwest -1 -1 0 -1 


ODD Y TILEWHALHING 


Again, you have four directions yet to figure out— north, northeast, southeast, and south. То move north 
and south, you can follow the crooked y-axis two steps, just as you did with the even y-coordinates. You 
will wind up with the same values— (0,-2) for north and (0,2) for south. 


To move northeast, you first move northwest to (x,y- 1) (even) and then move east to (x+ 1,y- 1) (even). 
To move southeast, you first move southwest to (x,y+ 1) (even) and then move east to (x+ 1,y+ 1) (even). 
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Finally, your staggered T ileW alker is complete, as shown in Table 13.3. 


Table 13.3 StaggeredTileWalker (Complete) 
Direction +-x(Eveny) +-у (Емеп у) +-х (Oddy) -y (Odd у) 


North 0 -2 0 -2 
N ortheast 0 -1 1 -1 
East 1 0 1 0 
Southeast 0 1 1 1 
South 0 2 0 2 
Southwest -1 1 0 i 
W est 1 0 1 0 
Northwest -1 -1 0 -1 


You could make aT ileW alker for staggered maps from this table, but you arent done just yet. You can 
streamline a few things about this table so that your T ileW alker will be more concise (and you wont have 
to have а bunch of 1+ statements to check for an even/ odd y-coordinate). 


T he first thing you'll notice is that the cardinal directions (north, south, east, west) are the same for both 
even and odd y values, so you dont need to have a special case for them. 


Also, the y changes for all the directions are the same for both even and odd y values, so you don't have to 
special-case those either. О nce you take the cardinal directions and the +/ -у columns out of the table, 
you are left with Table 13.4. 


Table 13.4 St TileWalker (Cardinal Direction 
+/-Y Removed) 

Direction — 4/-x (Even y) +/-x (Odd y) 

Northeast 0 1 

Southeast 0 


1 
Southwest -1 0 
Northwest -1 0 
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N ow you can observe the painfully obvious truth that was hidden when this data was strewn about the 
larger table. W hen y is odd, you add 1 to the +/ -x value T his means you can use y&1 to modify this 
value and create aT ileW alker that will work in both cases, without any special-case code! 


POINT StagMap_TileWalker(POINT ptStart,IsoDirection Dir) 
{ 


POINT ptDest=ptStart; 
switch(dir) 
{ 
case І50 МОКТН: 
{ 
ptDest.y-=2; 
}break; 
case ISO NORTHEAST: 
{ 
ptDest.y-; 
ptDest.x*-( ptStart.y&1); 
}break; 
case ISO EAST: 
{ 
ptDest.x++; 
}break; 
case ISO SOUTHEAST: 
{ 


ptDest.y++; 

ptDest.xt=( ptStart.y&l); 
}break; 
case ISO_SOUTH: 
{ 


ptDest.yt=2; 
}break; 
case ISO_SOUTHWEST: 
{ 


ptDest.y++; 

ptDest.x*-( ptStart.y&l-1); 
}break; 
case ISO WEST: 
{ 

ptDest.x++; 
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break; 
case ISO NORTHWEST: 
{ 


ptDest.y—; 
ptDest.x+=(ptStart.y&l-1); 
}break; 
} 
return(ptDest); 
} 


And there you have it— a reasonably concise staggered Т ileW alker, only one case for each direction, just 
like you had for the slide map T ileW alker. And that means it's time for an example. 


Load up 150Н ex13 2.cpp. Other than a difference іп theT ilePlotter and T ileW alker, this example uses the 
exact same code as 150Н ех12 3.cpp, which illustrates just how similar staggered and slide maps really аге, 
as far as plotting and walking. You'll see this code again in the next chapter. 


Figure 13.5 shows the output of IsoH ex13 2.срр.Т he cursor is centered on the screen (except near the 
edges), and the numeric keypad is used to move around the tilemap. You use the exact same scroller that 
you used in Chapter 12, which | think is a very cool thing. 


Figure 13.5 
Output of IsoHex13 2.cpp 
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MNIOUSEMAPFING IN STHGGERED MAPS 


| talked at great length about the M ouseM ap in the preceding chapter, but | won't have to here because the 
М ouseM ap is primarily based on theT ilePlotter and theT ileW alker. Because you've already changed these 
two components to accommodate your staggered map, you don't have to do anything to your 

M ouseM ap— it will still work just fine. 


Load up IsoH ex13_3.cpp.T his example is based on IsoH ех12_4.срр.Т he only differences exist in the 
T ilePlotter and T ileWalker. T he М ouseM ap code has not been touched. Figure 13.6 shows the output of 
IsoH «13 3.cpp. 


Figure 13.6 
Output of IsoHex13 3.cpp 
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О kay, | lied. | did change one other thing. | changed the cl ipScreenAnchor function to a more accurate 
version. In the older one, the screen anchor could have an x value equal to the right of the anchor space, 
and as we discussed in Chapter 2, "T heWorld of GD! and W indows Graphics,’ the right edge of the 
ВЕСТ iS not inside the RECT. 


void ClipScreenAnchor() 
{ 
//clip to left 
if (ptScreenAnchor.x<rcAnchorSpace. left) 
ptScreenAnchor.x=rcAnchorSpace. left; 
//clip to top 
if (ptScreenAnchor.y<rcAnchorSpace.top) ptScreenAnchor.y=rcAnchorSpace.top; 
//clip to right 
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if (ptScreenAnchor.x>=rcAnchorSpace. right) 
ptScreenAnchor.xercAnchorSpace.right-1; 

//clip to bottom 

if(ptScreenAnchor.y»-rcAnchorSpace.bottom) 
ptScreenAnchor.y=rcAnchorSpace.bottom-1; 


T his might seem like a minor change, but it is necessary, especially for what I’m about to show you. 


UNIQUE PROPERTIES OF 
STAGGERED MAPS 


U nlike the slide map, which always has the problem of the big, ugly black areas no matter what you do, 
staggered maps are more “rectangular” and so are ideally suited for certain tasks. Т he first of these tasks 15 
"no jaggies or the elimination of the ugly black triangles on the edges, and the other task is “wrapping 
around,” which is good for making cylindrical worlds. Both of these things can strongly enhance the look 
of your staggered map-based game. 


No JAGGIES 


First, | want to show you how to eliminate the jaggies. Surprisingly, this has nothing to do with the tiles 
image or any of the iso engine components. It just has to do with the scroller. In IsoH ex 13 4.срр, the 
code is almost identical to 150Н ex13 3.cpp, with the exception that | added and changed а few lines in 

SetUpSpaces. 


void SetUpSpaces() 

{ 
//set up screen space 
SetRect(&rcScreenSpace,0,0,640,480); 
//grab tile rectangle from tileset 
RECT rcTilel; 
RECT rcTile2; 
POINT ptPlot; 
POINT ptMap; 
//grab tiles from extents 
CopyRect(&rcTilel,&tsIso.GetTileList()[0].rcDstExt); 
CopyRect(&rcTile2,&tsIso.GetTileList()[0].rcDstExt); 
//move first tile to upper-left position 
ptMap.x=0; 
ptMap.y-0; 
ptPlot=StagMap_TilePlotter(ptMap,mmMouseMap.ptSize.x,mmMouseMap.ptSize.y); 
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OffsetRect(&rcTilel,ptPlot.x,ptPlot.y); 

//move first tile to lower-right position 

ptMap.x-MAPWIDTH-1; 

ptMap.y-MAPHEIGHT-1; 

ptPlot-StagMap TilePlotter(ptMap,mmMouseMap.ptSize.x,mmMouseMap.ptSize.y); 

OffsetRect(&rcTile2,ptPlot.x,ptPlot.y); 

//combine these two tiles into world space 

UnionRect(&rcWorldSpace,&rcTilel,&rcTile2); 

//copy world space to anchor space 

CopyRect(&rcAnchorSpace,&rcWorldSpace); 

//subtract screenspace 

//adjust right edge 

rcAnchorSpace.right-=(rcScreenSpace.right-rcScreenSpace. left); 

//make sure right not less than left 

if (rcAnchorSpace.right<rcAnchorSpace. left) 
rcAnchorSpace.right=rcAnchorSpace. left; 

//adjust bottom edge 

rcAnchorSpace. bottom-=(rcScreenSpace.bottom-rcScreenSpace. top) ; 

//make sure bottom not less than top 

if (rcAnchorSpace.bottom<rcAnchorSpace. top) 
rcAnchorSpace.bottom=rcAnchorSpace. top; 

//adjust edges of anchorspace for "no jaggies" 

//add 1/2 height to top 

rcAnchorSpace.topt-(mmMouseMap.ptSize.y/2); 

//subtract 1/2 height from bottom 

rcAnchorSpace.bottom--(mmMouseMap.ptSize.y/2); 

//add 1/2 width to left 

rcAnchorSpace. left+=(mmMouseMap. ptSize.x/2); 

//subtract 1/2 width from right 

rcAnchorSpace.right-=(mmMouseMap.ptSize.x/2); 

//initialize screen anchor 

ptScreenAnchor.x=rcAnchorSpace. left; 

ptScreenAnchor.y=rcAnchorSpace. top; 

//initialize cursor 

ptCursor. x=0; 

ptCursor.y-0; 


As you can see, the changes are pretty minor. You simply reduce your anchor space by half a tile on each 
edge and initialize the screen anchor to the top left of the screen space, where before you initialized it to 
(0,0). 


ISOMETRIC GAME PROGRAMMING WITH, DIRECTX 7,0 


Figure 13.7 shows the output of this program. You'll notice that it's similar to most of the rest of the 
examples in the chapter, except it has no jaggies. М ow that you have eliminated the jagged edges, you can 
certainly see how much more immersive the environment is. T hose jagged edges weren't serving any useful 
purpose. . . they just distracted you. 


< hc 3 Figure 13.7 
| Output of IsoHex13 4.cpp. 
No jaggies! 
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So, was that easy enough for you? Good. N ow move on to cylindrical staggered maps. 


CYLINDRICAL NAPS 


W hen 1 say gylindrical maps, what | mean is that you can move from the left edge to the right edge, and vice 
versa. In cases like these, the map is called cylindrical because if you were to print the map and put the left 
and right edges together, you would make a cylindrical tube. 


You can also make another type of map, one that not only moves continuously east and west, but also 
moves continuously moves north and south. T hese are called torus maps. If put into the real world, they 
would be doughnut-shaped. W e wont be dealing with torus maps today, but after you've learned how to 
make maps cylindrical, it's just a matter of doing the same thing in another direction. 


If you're sitting there clutching your heart, hyperventilating, and screaming, "But I'm not ready for this!”, 
calm down. А dax, breathe deeply, and have some herbal tea. Like most of the topics weve covered in our 
isometric discussions, it's a lot easier than it sounds. In fact, it's really easy. . . forehead-slapping easy, even. 
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Since you aren't yet detecting which tiles absolutely must be blitted for each screen (which you will be 
doing later) you have to render each tile twice T he basic rendering loop will look something like this (this 
is psuedocode, y'all): 


void RenderTiles() 
| for (y=0; y<MAPHEIGHT ; y++) 
| for (x=0;x<MAPWIDTH*2;x++)//the doubling takes place here 
| MapX-xZMAPWIDTH;//grab the tile that is supposed to go here 
PlotTile(x,y,TileMap[MapXILy1) ; 


} 


W hy do you render twice? W ell, in order to give the illusion of a continuous east-west edge, you have to 
write tiles “beyond the horizon,” or past the right edge You do not have to do this for the left edge You 
dont actually have to write all the tiles twice You could just do an extra screen width's worth, but since 

you currently have no particular relationship between screen and map, you must write all tiles twice. You 
might be saying, “But wont that decrease performance?” Y es, it certainly will. Right now, though, you're 
working on getting stuff done Performance comes later. 


Load up IsoH ех13 5.срр. Essentially, it is a modified IsoH ex13 4, but now you can smoothly scroll left 
or right forever. О nly а few tweaks are necessary to make this happen. First, you need to modify DrawMap 
in order to write each tile twice (as | demonstrated earlier). | have underlined the lines | had to change 
from thelsoH ex13 4 version. 


void DrawMap() 
{ 


POINT ptTile;//tile pixel coordinate 

POINT ptMap;//map coordinate 

//the y loop is outside, because we must blit in horizontal rows 
for(int y=0;y<MAPHEIGHT; у++) 

{ 


for(int х=0; х<МАРИТОТНХ2 ; х++) 
{ 


//get pixel coordinate for map position 
ptMap.x=x; 
ptMap.y=y; 
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ptTile=StagMap_TilePlotter(ptMap,mmMouseMap.ptSize.x,mmMouseMap.ptSize.y); 
//plot the tile (adjust for anchor) 
tsIso.PutTile(l1pddsBack,ptTile.x-ptScreenAnchor.x,ptTile.y- 
ptScreenAnchor.y,iTileMap[ xZ2MAPWIDTH][y ]): 
} 


N ext, you have to modify the anchor space (in the SetUpSpaces function) to add a screen width to it. 
Since you are already subtracting a screen width from anchor space, you'll just remove that part. Also, you 
have to eliminate the right edge adjustment that you used in the “no jaggies" example. Н ere is the modi- 
fied code, with underlined changes: 


void SetUpSpaces() 
{ 
//set up screen space 
SetRect(&rcScreenSpace,0,0,640,480); 
//grab tile rectangle from tileset 
RECT rcTilel; 
RECT rcTile2; 
POINT ptPlot; 
POINT ptMap; 
//grab tiles from extents 
CopyRect(&rcTilel,&tsIso.GetTileList()[0].rcDstExt); 
CopyRect(&rcTile2,&tsIso.GetTileList()[0].rcDstExt); 
//move first tile to upper-left position 
ptMap.x-0; 
tMap.y-0; 
tPlot-StagMap TilePlotter(ptMap,mmMouseMap.ptSize.x,mmMouseMap.ptSize.y); 
FffsetRect(&rcTilel,ptPlot.x,ptPlot.y); 
/move first tile to lower-right position 
tMap.x=MAPWIDTH-1; 
tMap.y-MAPHEIGHT-1; 
tPlot=StagMap_TilePlotter(ptMap,mmMouseMap.ptSize.x,mmMouseMap.ptSize.y); 
OffsetRect(&rcTile2,ptPlot.x,ptPlot.y); 
//combine these two tiles into world space 
UnionRect(&rcWorldSpace,&rcTilel,&rcTile2); 
//copy world space to anchor space 
CopyRect(&rcAnchorSpace,&rcWorldSpace); 
//subtract screen space 
//adjust right edge (removed) 
//make sure right not less than left 
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if (rcAnchorSpace.right<rcAnchorSpace. left) 


rcAnchorSpace.right=rcAnchorSpace. left; 
//adjust bottom edge 
rcAnchorSpace.bottom-=(rcScreenSpace.bottom-rcScreenSpace. top) ; 
//make sure bottom not less than top 
if (rcAnchorSpace.bottom<rcAnchorSpace. top) 

rcAnchorSpace.bottom=rcAnchorSpace. top; 
//adjust edges of anchorspace for "no jaggies" 
//add 1/2 height to top 
rcAnchorSpace. topt=(mmMouseMap.ptSize.y/2); 
//subtrac 
rcAnchorSpace.bottom-=(mmMouseMap 


//add 


1/2 


t 1/2 height from botto 


width to left 


rcAnchorSpace. left+=(mmMouseMap.p 


//elimi 


na 


te right edge adjustment 


// initi 


al 


ize screen anchor 


ptScreenAnchor.x=rcAnchorSpace.le 
ptScreenAnchor.y=rcAnchorSpace. top; 


//initi 


alize cursor 
ptCursor. x=0; 
ptCursor.y-0; 


.ptSize.y/2); 


tSize.x/2); 


ft: 


So, what's all this about? W all, in order to give the illusion of wrapping forever, you have to allow the 
screen to sweep past the right edge by an entire screen width. T his is what you did by eliminating the sub- 
traction of the screen width from the anchor space. N ow, since the left edge has been adjusted by half a 
Ше уои must do the same to the right edge (which you did before by subtracting half of the tile width, 
leaving you with a net zero change to the right edge), so that when you scroll from one edge to the other, 
there isnt a "skip" of anything, and the scrolling is nice and smooth. 


Penultimately, you have to modify your c1 ipScreenAnchor function so that it moves cleanly from one 
horizontal edge to the other. T his is done simply by checking to see whether the anchor has passed one of 
the edges, and adding or subtracting the width of the anchor space to bring it back into the proper range: 


void ClipScreenAnchor() 


{ 


//wrap to left 
if (ptScreenAnchor.x<rcAnchorSpace. left) 
ptScreenAnchor.x+=(rcAnchorSpace.right-rcAnchorSpace. left); 
//clip to top 
if (ptScreenAnchor.y<rcAnchorSpace.top) ptScreenAnchor.y=rcAnchorSpace.top; 
//wrap to right 
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if (ptScreenAnchor.x>=rcAnchorSpace.right) ptScreenAnchor. x- 
=(rcAnchorSpace.right-rcAnchorSpace.left);; 

//clip to bottom 

if (ptScreenAnchor.y>=rcAnchorSpace. bottom) 
ptScreenAnchor.y=rcAnchorSpace.bottom-1; 
} 


Finally, you have to remove the restriction that the cursor cannot go beyond the right edge of the map, by 
eliminating a single line in your им м005ғмоуғ handler: 


case WM_MOUSEMOVE: 
{ 

//grab mouse coordinate 

POINT ptMouse; 
ptMouse.x=LOWORD(1Param) ; 
ptMouse. y=HIWORD(1 Param) ; 
//mousemap the mouse coordinates 
ptCursor=StagMap_MouseMapper(ptMouse, &mmMouseMap) ; 
//clip cursor to tilemap 
if(ptCursor.x«0) ptCursor.x-0; 
if(ptCursor.y«0) ptCursor.y=0; 
/lif(ptCursor.x»MAPWIDTH-1) ptCursor.x-MAPWIDTH-1;(eliminated) 
if( 


1 
ptCursor.y>MAPHEIGHT-1) ptCursor.y=MAPHEIGHT-1; 
/*REST OF CODE OMITTED FOR BREVITY*/ 


And that's it! Y ouve got an east-west "scroll forever” staggered map. See how easy it was? Plus, now the 
world looks endless, even though you know it is of finite size. 


SUMMARY 


In this chapter, you got into some pretty cool stuff. Granted, these examples are still rather elementary, but 
hopefully you're starting to feel comfortable with isometric graphics. As I've said several times, they really 
arent as complicated as everyone seems to think. 
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his chapter presents the final type of isometric map— the diamond map. [п the past, | ve been 

known to call these "diagonal" maps because of the direction of both axes. T his type of map is 
probably the most familiar and the most commonly used, mainly in the area of real-time strategy games 
like Age of Empire A ge of К ingdoms, Sim C ity 2000/ 3000, Rolle С oaste Tycoon, and a wide variety of simula- 
tions. Diamond maps, it seems, are the perfect choice for real-time isometric games. Т hose are not the only 
uses, of course T he world of board games— chess, checkers, Reversi, and so on— can really benefit from 
these types of maps, since they look far superior to the boring top-down views of ages old. 


COORDINATE SYSTEM 


W hile there are several ways to go about using a diamond map, the simplest that | have found makes the 
top corner into map position (0,0). You could pick any corner you wanted, and do {пет ilePlotter and 
T ileWalker figuring, and it would work just fine. In fact, | have in the past used the leftmost corner as 
(0,0), so it really doesnt matter. 


T he following basically describes the coordinate system of the diamond maps | present here: 


= T heorigin is at the top corner of the map. 
= T he x-axis increases to the southeast. 
= T he y-axis increases to the southwest. 


T he coordinate system is shown in Figure 14.1. 


Figure 14.1 


Coordinate system of 
diamond maps 
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T he diamond map isnt by any means as tricky as staggered maps, but it is a bit more complex than the 
slide map. Its little quirks will become apparent as we move on. 


TILEFLOTTING 


As usual, your first task in a new style of map is to be ableto plot the tiles. In this area, the diamond map 
shows the first of its little quirks. U nlike both slide and staggered maps, which have the x-axis moving 
east- west, the diamond map has a diagonal axis. W hile this is odd, it doesnt hold you up for long, because 
you've already dealt with diagonal axes, mainly in the arena of the y-axis for the other types of map. 


T he x-axis increases to the southwest, just as the y-axis does in slide maps. In slide maps, you determined 
that to move southeast, you must move east half а tile and south half a tile You will do the same 
thing here. 


//MapX is a map coordinate, PlotX and PlotY are world coordinates 
PlotX-MapX*TileWidth/2; 
PlotY-MapX*TileHeight/2; 


Of course, you still have the map’s y-coordinate to take into account. Since y moves to the southwest, you 
must move half а tile to the west (multiply by -ri1ewidtn/2) and half а tile to the south (multiply by 
TileHeight/2). From this value, modify P1otx and Ploty. 


//MapY is a map coordinate, PlotX and PlotY are world coordinates 
//from the last code snippet 
PlotX--(MapY*(-TileWidth/2)); 
PlotYt+=(MapY*(TileHeight/2)); 


You would like to have the two parts of this tileplotting placed into fewer lines than this, so let's rewrite it: 
//MapX,MapY=map coord; Р10%Х, PlotY=world coord 
PlotX-MapX*TileWidth/2-MapY*TileWidth/2; 
PlotY=MapX*TileHeight/2+MapY*TileHeight/2; 


Or, you might like to have only one multiplication per line 


PlotX=(MapX-MapY )*TileWidth/2; 
//you could further eliminate the /2 by using >>1 instead 
PlotY=(MapX+MapY )*TileHeight/2; 


Both map axes affect both world axes as far as tileplotting goes, which is something you haven't seen in the 
other map types. T his seems like one of the more difficult parts of using diamond maps, but as you can 
see, it's not really hard at all. 
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THE TILEPLOTTING FUNCTION 
You will base your T ilePlotter on theT ilePlotters of previous chapters, for consistency. 


POINT DiamondMap TilePlotter(POINT ptMap,int iTileWidth,int iTileHeight) 
{ 


POINT ptReturn; 
ptReturn.x=(ptMap.x-ptMap.y)*iTileWidth/2; 
ptReturn.y=(ptMap.x+tptMap.y)*iTileHeight/2; 
return(ptReturn) ; 

} 


Simple enough? Good. T ime for an example? You betcha! 


Al DIAMOND MAP TILEPLOTTING DEMO 


Load up 150Н ех14 1.срр. It's the diamond map plotting demo, based mainly on code from IsoH ex12_ 1, 
which was the slide map plotting demo. T he main difference is the replacement of {Пет ilePlotter. 


You can see what this example looks like in Figure 14.2. IsoH ех14 1.cpp reveals yet another quirk of the 

diamond map. Some of the map extends off the left side of the screen. Since you are not currently scroll- 

ing and are not using an anchor to correct your coordinates, this means that a diamond map extends into a 
negative-valued world coordinate— not really a big deal, because you already have compensation for this in 

your M ouseM ap (remember the “negative numbers” chat we had two chapters ago?) 


Figure 14.2 
Output of IsoHex14 1.cpp 
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Білттімес ORDER 


О ne last topic | want to discuss, as far as diamond maps are concerned, is blitting order. | told you in the 
last two chapters that blitting should be done in horizontal rows if possible. Т here was no problen doing 
this with slide maps and staggered maps, because with both, the x-axis travels east-west. 


H owever, diamond maps are a different story. Currently, without aT ileW alker, you cant move east or west, 
and your axes travel in diagonal lines. T his is one of the reasons | picked the topmost corner for tile (0,0): 
so that the rendering order is acceptable enough that you won't have to change the DrawMap function. You 
can simply iterate through map y values, and inside that loop have another loop that iterates through the 
map x values, and plot accordingly. In a later chapter, | will show you how to blit in horizontal rows, no 
matter what the map looks like. 


SCROLLING REVISITED 


Because of the strange orientation of diamond maps, | need to discuss scrolling, at least for a moment. 
Yet another quirk. 


In slide and staggered maps, construction of the world space rectangle is rather straightforward. Simply 
take the extents from the upper-left and lower-right corner tiles and use Uni onRect to combine them into 
alarger RECT. 


If you did the same thing with a diamond map, where (0,0) is the topmost corner and (MAPWIDTH- 
1,MAPHEIGHT-1) is the bottommost corner, you would have а rather narrow strip for world space. Instead, 
you have to also bring the left and right corners into the union, like so: 


//grab tile rectangle from tileset 
RECT rcTilel; 

RECT rcTile2; 

RECT rcTile3; 

RECT rcTile4; 

POINT ptPlot; 

POINT ptMap; 

//grab tiles from extents 
CopyRect(&rcTilel,&tsIso.GetTileList()[0].rcDstExt); 


) 

CopyRect(&rcTile2,&tsIso.GetTileList()[0].rcDstExt); 
) 
) 


CopyRect(&rcTile3,&tsIso.GetTileList()[0].rcDstExt); 
CopyRect(&rcTile4,&tsIso.GetTileList()[0].rcDstExt); 
//move first tile to top corner 

ptMap.x=0; 

ptMap. y=0; 

ptPlot-DiamondMap TilePlotter(ptMap,iTileWidth,iTileHeight); 
OffsetRect(&rcTilel,ptPlot.x,ptPlot.y); 
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//move to bottom corner 
ptMap.x=MAPWIDTH-1; 
tMap.y-MAPHEIGHT-1; 


mue зе 


p 
ptPlot-DiamondMap TilePlotter(ptMap,iTileWidth,iTileHeight); 
OffsetRect(&rcTile2,ptPlot.x,ptPlot.y); 

//move to left corne 
ptMap.x-0; 
ptMap.y-MAPHEIGHT- 
p 

0 

/ 

p 

p 

p 


ze 


tPlot-DiamondMap TilePlotter(ptMap,iTileWidth,iTileHeight); 
FffsetRect(&rcTile3,ptPlot.x,ptPlot.y); 

/move to right corner 

tMap.x=MAPWIDTH-1; 
tMap.y=0; 
tPlot-DiamondMap TilePlotter(ptMap,iTileWidth,iTileHeight); 
OffsetRect(&rcTileA4,ptPlot.x,ptPlot.y); 

//combine these four tiles into world space 
UnionRect(&rcWorldSpace,&rcTilel,&rcTile2); 
UnionRect(&rcWorldSpace,&rcWorldSpace,&rcTile3); 
UnionRect(&rcWorldSpace,&rcWorldSpace,&rcTile4); 


T he rest of the spaces (screen space and anchor space) remain unaffected. O nly the world space 
is changed. 


Al DIAMOND MAP SCROLLING Demo 


It's time for те to show instead of tell. IsoH ех14 2.срр is the next example. It is patterned quite closely 
after 150Н ех12 2.срр. Т he differences are that this example uses the diamond map Т ilePlotter and imple 
ments the changes to the world space calculation. T he actual code was changed slightly, since! didn’t want 
to use a UnionRect Call with the destination pointer also serving as a source pointer. (D oing stuff like that 
always makes me nervous.) You can see what this example looks like in Figure 14.3. 


U se the arrow keys to scroll through the map. Pretty neat, huh? And to think that almost half of the 
world space has a negative x value, but our little plotter/ scroller combination doesnt really care. T hat's part 
of the beauty of these engine components— they're like little black boxes that take your input and spew 
the proper output. 
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TILEWALKING 
With the many other diamond map quirks, it would be reasonable to assume that tilewalking is quirky. 


T his reasonable assumption would be wrong. T ilewalking in a diamond map is totally regular (unlike the 


staggered map), as you will see during its derivation. 


You start with the knowledge of two things: x increases to the southeast, and y increases to the southwest. 
Let's start with Table 14.1. 


Figure 14.3 
Output of IsoHex14 2.cpp 


Table 141 DiamondTilewalking (Initial) 


Direction 
North 
Northeast 
East 
Southeast 
South 
Southwest 
W est 
Northwest 


Change x 


3 dou-us 


Change y 


3 douHosdssgs 
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From this point, you can easily figure out the northeast and northwest directions. Because they are the 
opposites of southeast and southwest, they are located opposite then. Table 14.2 reflects this. 


Table 14.2 DiamondTilewalking (All Diagonals) 
Direction Change x Change у 


North 7? 7? 
N ortheast 0 -1 
East 7 7? 
Southeast 1 0 
South 7? 7 
Southwest 0 1 
W est 7? 7? 
Northwest -1 0 


H ey! You're halfway done already. You've got all your diagonals, and deriving the cardinal directions will be 
easy. You'll just use the two-step method to figure them out. 


To move north, you move one step northeast (0,-1) and one step northwest (- 1,0), which gives you 


(-1-1). 

Step Change x Change y 

N ortheast 0 -1 

Northwest -1 0 

Total -1 -1 

To move south, you move one step southeast (1,0) and one step southwest (0,1), which gives you (1,1). 
Step Change x Change y 

Southeast 1 0 

Southwest 0 1 


Total 1 1 
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To move east, you move one step southeast (1,0) and one step northeast (0,-1), which gives you (1,- 1). 


Step Change x Change y 

Southeast 1 0 

Northeast 0 -1 

Total 1 -1 

То move west, you move one step southwest (0,1) and one step northwest (- 1,0), which gives you (- 1,1). 
Step Change x Change y 

Southwest 0 1 

Northwest -1 0 

Total -1 1 


N ow youre done, and you can complete your table (seeT able 14.3). 


Table 14.3 DiamondTilewalking (All Diagonals) 
Direction Change x Change y 


North -1 -1 
N ortheast 0 -1 
East 1 -1 
Southeast il 0 
South 1 1 
Southwest 0 1 
W est -1 1 
Northwest -1 0 
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You finally have all the information you need to construct your T ileW alker function. See how easy that 
was? O nce you know one type of map, you know them all. 


POINT DiamondMap_TileWalker(POINT ptStart,IsoDirection Dir) 
{ 


switch(dir) 
{ 
case 150 МОКТН: 
{ 
ptStart.x-; 
ptStart.y-; 
break; 
case ISO NORTHEAST: 
{ 
ptStart.y-; 
break; 
case ISO_EAST: 
{ 
ptStart.x++; 
ptStart.y-; 
break; 
case ISO_SOUTHEAST: 
{ 
ptStart.x++; 
break; 
case ISO SOUTH: 
{ 
ptStart.x++; 
ptStart.y++; 
}break; 
case ISO_SOUTHWEST: 
{ 


ptStart.y++; 
break; 
case ISO_WEST: 
{ 
ptStart.x-; 
ptStart.y++; 
break; 
case ISO NORTHWEST: 
{ 
ptStart.x-; 
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}break; 
} 
return(ptStart); 


} 


T he output of 150Н ех14 3.срр is shown in Figure 14.4. 


Figure 14.4 
Output of IsoHex14 3.cpp 


It's time to put your new T ileW alker into service. Load up IsoH ех14 3.cpp, which looks suspiciously like 
IsoH ex12_3.cpp, except for the change from slide to diamond. In this example, you can use the keyboard 
to move around the map, and the current cursor location will be centered as much as possible based on the 
апсһог5 position in anchor space. N ear the corners, at least one direction will not be centered. 


rYlousegmm-rmriNG 


Ah, the final component— the M ouseM ap. Like theT ileW alker, the M ouseM ap ends up being not quirky 
at all, since you already learned how to handle a negative world coordinate back in Chapter 12, "Slide 
Isometric T ilemaps" М ouse mapping has been covered so well, in fact, that there is little to do now except 
plug it into the program. T he exact same M ouseM ap that we used in Chapters 12 and 13 will work 

just fine 
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So, without further ado, load up IsoH ех14_4.срр (again, it's based on IsoH ех12 4.срр). Like its prede 
cessor, you can scroll about the map by putting the mouse pointer at one of the edges, and the cursor will 
be shown on the proper tile. Figure 14.5 shows what it looks like. 


Figure 14.5 


IsoH ex14 4.срр in action 


Га like to point out here that, for the examples in these chapters, it took me about 5 minutes to convert 
them from their Chapter 12 equivalents. | just had to replace the code in the various isometric engine 
components, and whammo, | was done. T his goes а long way toward showing how universal these 
dements are. 


SUMMARY 


T his chapter might seem a little light compared to how much time we spent on the other two types of 
tilemaps. On the contrary. All of the discussion for the other types of maps made diamond maps need 
almost no explanation. 


N ow that | ve introduced the three types of isometric maps, | hope youre starting to get some ideas as to 
how you want to use them to make games. And youre probably wondering about various issues, like how 
to put objects in an isometric map. Rest assured that all of your questions shall be answered. 

You are now equipped with the basic idea of how 150Н ex engines work fundamentally. You have been 
introduced to theT ileP lotter, Т ileWalker, and М ouseM ap (as well as the Scroller, which is not in itself an 
І5ОН ex component). We will build on this foundation 
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ood news: | have finally finished the introductory subject matter... well, almost. T his chapter is 
the last bit. It introduces the [50Н exCore engine, which is essentially a small library of classes 
that wrap up everything I ve talked about for the past three chapters. 


OVERVIEW OF ISOHEXCORE 


A number of files are contained in the 150Н exCore engine: a main header file that includes all the compo- 
nents, a header file/ source file pair for each of the four components, and finally a header file for the uni- 
versal definitions required for an isometric engine. 


Table 15.1 lists the files contained in IsoH exCore and briefly describes their contents. 


Table 15.1 IsoHexCore Files 


File W hat It Contains 

IsoH exD efs.h Fundamental enumerations for other components 
IsoTilePlotter.h Declarations for the CTilePlotter class 
IsoTilePlotter.cpp Implementation for the CTilePlotter class 
IsoTileW alker.h Declarations for the CTileWalker class 

IsoTileW alker.cpp Implementation for the CTileWalker class 
IsoScroller.h Declarations for the С5сго11ег class 
IsoScroller.cpp Implementation for the CScroller class 

Iso MouseM ap.h D eclarations for the CMouseMap class 

IsoMouseM ap.cpp Implementation for the CMouseMap class 


IsoHexCore.h All other components in a single header 
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As you can see, the files mirror the fundamental compo- 


nents of any isometric engine T ileP lotter, T ileW alker, NOTE 
M ouseM ap, and scroller. T hey are split into different None of these components are what 
files to make the engine a bit more manageable. Т he file you'd call “game-worthy.” T hat is, the 
listed last, 150Н exCore.h, brings all the headers together. code | present here is nowhere close 
It's the only file you need to include in your project. to the performance you could get 
| | from a highly optimized isometric 
One by one, in the same order as the table, |11 show you engine.The code is meant to be easi- 
each of these components, explain how they were put ly read and understood, not neces- 
together, and show how they are intended to be used. sarily the fastest in the world.W hen 
it comes time to write real code for 
your own isometric engine, | expect 
TSQOHEXDEFSsH you to write stuff that leaves this lit- 
T his file, the full contents of which are shown next, con- Че engine in the dust! 


tains exactly two enumerations: one for the isometric 
directions (I1SODIRECTION), and one for the different 
isometric map types (150МАРТҮРЕ). 


//the isometric directions 
typedef enum 
{ 


SO_NORTH=0, 
SO_NORTHEAST=1, 
S0 EAST-2, 

S0. SOUTHEAST-3, 
SO SOUTH-4, 

SO SOUTHWEST-5, 
S0 WEST-6, 

SO. NORTHWEST-7 


} ISODIRECTION; 
//directional turning macros 

#аећпе 150 TURNRIGHT(dir,turn) (ISODIRECTION) CCCint) (dir)+(turn) )&7) 
ІМейпе ISO_TURNLEFT(dir,turn) (ISODIRECTION)((Cint)(dir)+(turn)*7)&7)//iso 
map types 

typedef enum 

{ 


ISOMAP SLIDE, 

ISOMAP STAGGERED, 

ISOMAP DIAMOND, 

ISOMAP RECTANGULAR 
} ISOMAPTYPE; 
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I'll spend some time explaining each of these enumerations and how they are used. T hey have widespread 
effects on the rest of IsoH exCore. 


1= QODIRECTION 


ISODIRECTION Was used before, in theT ileWalkers and M ouseM aps, and that is essentially what they are 
for now. H owever, those arent the only use for this enumeration. You can also keep track of which way 
something is facing during your game and use the macros provided that allow turning. T he enumeration 
constants and directions are shown in figure 15.1. 


Each direction has an assigned number, which is unusual for any sort of enumeration. M ost either don't 
specify values at all or just specify the value of the first identifier and let the compiler figure out the rest. | 
could have done either of these and come out with the same values I'm currently assigning. M у reasons for 
assigning these numbers, and for employing the order that | do, is so that 0 means north and the rest of 
the directions are determined by slowly turning clockwise. Т his is what makes the turning macros 
(explained next) work. 


Figure 15.1 
ISO NORTH ISODIRECTION values 


ISO NORTHWEST ISO NORTHEAST 


ISO WEST 


ISO SOUTHWEST ISO SOUTHEAST 
E ISO SOUTH 
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TSQODIRECTION MACROS 


ISODIRECTION macros allow you to turn from one heading to another. 


//directional turning macros 
#аећпе 150 TURNRIGHT(dir,turn) (ISODIRECTION) CCCint) (dir)+(turn) )&7) 
]9ейие 150 TURNLEFT(dir,turn) (ISODIRECTION)(( (int) (dir)+(turn)*7)&7) 


In each case, dir represents an initial direction, and turn represents the number of 45-degree turns to 
make. H ence, to turn 90 degrees left from north, you would use this: 


SODIRECTION Dir-ISO TURNLEFT(ISO, NORTH,2);//assigns ISO WEST to Dir 
T his expands to 
SODIRECTION Dir-(ISODIRECTION) (CCint) (ISO. NORTH)-(2)*7)87) ; 


SODIRECTION Dir=(ISODIRECTION) ((0+14)&7); 


SODIRECTION Dir=(ISODIRECTION) (14&7); 


SODIRECTION Dir=(ISODIRECTION) (6); 


And 6 is the value of 150 wesr, which is the correct answer. | am not a big fan of macros, but in simple 
cases like these, the extra overhead of a function is really unnecessary. | still dont advocate the heavy use of 
macros and defines. T hey make debugging more difficult than it has to be. 


ІН ОТҮТНІРТҮРЕ 


150МАРТҮРЕ contains identifiers for the various styles of isometric maps. In its current state, |soH exCore 
supports four map types: slide, staggered, diamond, and rectangular. Yes, it supports rectangular, mainly to 
show how similar rectangular tile-based games are to isometric tile-based games. 


You dont really do much with the т50МАРТУРЕ enumeration other than supply its values to your 
T ilePlotter and T ileWalker. Figure 15.2 shows the differences between the values of ISOMAPTYPE. 
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Figure 15.2 


ISOMAPTYPE values 
and their meanings 


ISOMAP SLIDE ISOMAP STAGGERED 


ISOMAP DIAMOND 


TSOTILEPLOTTERsH/ 
ISOTILEPLOTTERs«Ccrr 


N ow that you've got the isometric fundamentals down, you can start to get serious. T he IsoT ilePlotter.h 
and IsoT ilePlotter.cpp files contain the code necessary for the cri1eP1otter Class, the declaration of 
which is shown here: 


HIM MMLBMIMIIIIB BB MIL IL M LIII ZI M I! 
//typedef for tile plotter function pointer type 
VAILATI AALE ИИ ИИ 
typedef POINT (*ISOHEXTILEPLOTTERFN)CPOINT ptMap,int iTileWidth,int iTileHeight); 
//////////////////////////////////////////////////////////// 
//tile plotter class 
//////////////////////////////////////////////////////////// 
class CTilePlotter 
{ 
private: 

//type of map 

ISOMAPTYPE IsoMapType; 

//width and height of tiles 

int iTileWidth; 

int iTileHeight; 

//function called to calculate plotted tiles 

ISOHEXTILEPLOTTERFN IsoHexTilePlotterFn; 
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public: 
//constructor/destructor 
CTilePlotter(); 
~CTilePlotter(); 
//map type 
void SetMapType(ISOMAPTYPE IsoMapType); 
ISOMAPTYPE GetMapType(); 
//tile size 
void SetTileSize(int iTileWidth,int iTileHeight); 
int GetTileWidth(); 
int GetTileHeight(); 
//plot a tile 
POINT PlotTileCPOINT ptMap); 


ү 
T his component has two main parts: the [SOHEXTILEPLOTTEREN type and CTilePlotter itself. 


TSQOHEXTILEPLOTTERFN 


T he following ugly little declaration is the main reason that you can make a single Ti 1eP1otter Class 
without having to incorporate any sort of inheritance or other object-oriented mechanism: 


typedef POINT (*ISOHEXTILEPLOTTERFN) (POINT ptMap,int iTileWidth,int iTileHeight); 


If you're confused, dont worry too much. T his is how you declare a function pointer type In С/С++, а 
function is really no different from a variable, except that it has parentheses afterwards. Take, for instance, 
the following two lines of code 


int x;//variable 
int x();//function 


See?T he only difference is the ( ) at the end of the second line. In all other ways, the declarations look identi- 
cal. But if you wanted x to bea pointer to a function that takes no parameters, you would have to do this: 


int (*x)();//ugly, ain't it? 

"But wait!” you say. “Couldnt | just do this...” 
int ХС 

“апа accomplish the same thing?” 


Sorry, but no. int *x(); isa function that returns a pointer to an integer, not a variable that contains a 
pointer to a function that takes no parameters and returns an int. See the difference?T hat's why you have 
to put parentheses around the * and the variable name, because the makers/ extenders of С/С++ havent 
come up with a better way to swrite function pointer variables. O ther languages, such as Pascal, have much 
better mechanisms. 
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So, back to the declaration. You already know how to declare pointers to function variables. T he next task 
is to figure out what the type of the function pointer is. [п the declaration int x; x is of type int, so you 
can conclude that taking the variable name and the semicolon out of the declaration will give you the type. 
Let's try it. If you remove x and ; from int (*x)();, you are left with int (*) O as the type. Boy, this is 
getting uglier by the second. Luckily, you're almost done. Н aving icky definitions like int (*)() makes 
your code unsightly, so you want to avoid this as much as possible by using a typedef. 


N ormally, you do a typedef as follows: 
typedef OriginalType TYPEALIAS; 


Alas, function pointer types screw you up again, because of the backward way you have to declare then. 
You have to put the name of the type after the >, so if you want to have a type of function pointer that 
takes no parameters and returns an int called INTFUNCPTR, you have to have the following typedef: 


typedef int (*INTFUNCPTR)(); 


N ow the nightmare is over, and thank goodness! N ow you can have some declarations like these: 


nt func();//function 

NTFUNCPTR x;//variable that points to a function that takes no parameters and 
returns an int 

x-func;//no ( ) when assigning a function pointer to an existing function 

int y=x();//call the function that x points to 


15 your head swimming yet? Function pointers are about the most confusing aspect of the С/С++ lan- 
guage. T he declarations are messy, but they can gain you a lot of power if used correctly. 


Back to the ISOHEXTILEPLOTTERFN type T he way that this type is declared, a variable of this type can be 
assigned to any function that looks like the following: 


POINT func(POINT pt,int il,int i2);//the actual names of the parameters 
//are unimportant. 


Only the type matters. 
ISOHEXTILEPLOTTERFN x=func;//assigns function's pointer to variable 
POINT ptl-x(pt,il,i2);//calls the function 


Н eres what makes this cool: IsoT ilePlotter.cpp has four functions, which I ve listed here: 


//plotting function prototypes 

POINT IsoHex SlidePlotTile(CPOINT ptMap,int iTileWidth,int iTileHeight); 
POINT IsoHex StagPlotTile(POINT ptMap,int iTileWidth,int iTileHeight); 
POINT IsoHex DiamondPlotTile(CPOINT ptMap,int iTileWidth,int iTileHeight); 
POINT IsoHex RectPlotTile(POINT ptMap,int iTileWidth,int iTileHeight); 
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In case you didnt notice, all of these functions can have their pointers held by any variable of type 150- 
HEXTILEPLOTTERFN. T his means that you can just keep one of these function pointers somewhere and use 
it to call whatever function you need to in order to plot your tiles correctly. Also, you could add more 
functions and allow expansion into other types of tile-based games (there are more than just isom&ric, 
hexagonal, and rectangular, you know). 


ISOHEXTILEPLOTTERFN is important to cTilePlotter, and a similar mechanism comes into play with 
CTileWalker to switch tilewalking functions. 


CTILEPLOTTER 


After that too-long treatise on the why and wherefore of function pointers, I'm sure you want to take а 
break with something simpler, like how quantum mechanics affect the speed of light in a total vacuum. 
Well, that is a fascinating subject, and 10 love to pursue it with you sometime, but right now I'd rather talk 
about cTilePlotter. Н ope you dont mind. Like all of my classes, cTi1ePlotter is divided into two 
parts: the private area that stores the data for the class, and the public area that has all of the functions 
that operate on the data. 


DATA MEMRERS 


CTilePlotter has a modest number of data members— four in total. Table 15.2 lists them and explains 
their purposes. 


Table 15.2 CTilePlotter Data Members 


Member Purpose 

IsoMapType Type of map with which this plotter is to be used 
iTileWidth W idth of a tile. Used to calculate plotted tiles. 
iTileHeight Height of a tile. Used to calculate plotted tiles. 


IsoHexTilePlotterFn Pointer to a function that does the actual tile plotting 


Each of thefollowing data members is pretty self-explanatory, but let's go over them briefly anyway. 


= IsoMapType. IsoMapType Stores the map type you are using (150МАР SLIDE, ISOMAP_STAGGERED, 
150МАР DIAMOND, Or ISOMAP. RECTANGULAR). It is set by CTilePlotter::SetMapType and retrieved 
by CTilePlotter::GetMapType.T his member is directly related to the value in the 
IsoHexTilePlotterFn member. 
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= iTileWidth/iTileHeight. T hese two members are used in the actual calculation of a tile plot. T hey are 
sent to the tileplotting function (stored in IsoHexTilePlotterFn), along with the map position that is 
being plotted. T hese members can be retrieved using CTilePlotter::GetWidth and 
CTilePlotter: :GetHeight. 

= IsoHexTilePlotterFn. It is strange to think that the real work done by CTilePlotter isnt even done 
by the class itself, but rather is sent to a function that is outside of it. IsoHexTilePlotterFn points to 
that function. N o member functions directly access this member. It is set when a call to SetMapType occurs. 


Мем Ее FUNCTIONS 


Like data members, cTilePlotter has a small number of member functions— eight in total. Table 15.3 
lists them and briefly explains their purpose. 


Table 15.3 CTilePlotter Member Functions 


Member Function Purpose 

CTilePlotter() Constructs the object, sets defaults 
~CTilePlotter() Destroys the object 

void SetMapType Sets the type of map used by the plotter 
(ISOMAPTYPE IsoMapType) 

ISOMAPTYPE Retrieves the type of map used by the plotter 
GetMapType() 

void SetTileSize Sets the size of the tile used in tile plot calculations 


(int iTileWidth, 
int iTileHeight) 


int GetTileWidth() Retrieves the width of the tile used to calculate tile plots 
int GetTileHeight() Retrieves the height of the tile used to calculate tile plots 
POINT PlotTile Plots the world space coordinate from a map coordinate 


(POINT ptMap) 


| further subdivide these member functions into four groups: Construction/ D estruction, MapType, 
TileSize, and Plotting. 


CONSTRUCTION/ DESTRUCTION FUNCTIONS 


T he constructor (cTilePlotter()) and the destructor (~cTilePlotter()) dont do much and arent 
really very interesting. In fact, the destructor is completely empty. (I make а habit of making classes with a 
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destructor, just in case | need it later.) T he constructor simply sets the map type to ISOMAP_RECTANGULAR 
and sets the tile size to a width and haght of 1.T his means that the default behavior of an instance of 
TilePlotter plots a point to the exact same coordinate 


CTilePlotter::CTilePlotter(); 

his assigns default values to map type and tile size 
CTilePlotter::~CTilePlotter(); 

T his does nothing. 


Сэ 


Ho 


MAPTYPE FUNCTIONS 


Two CTilePlotter functions have to do with the 1soMapType and IsoHexTilePlotterFn data members 
(indirectly). SetMapType assigns a new map type to the plotter (and selects the proper plotting function 
for IsoHexTilePlotterFn), and GetMapType returns the plotter's currently assigned map type. 


void CTilePlotter::SetMapType(ISOMAPTYPE IsoMapType) ; 
T his sets a new map type for the plotter. It does not return a value. 
ІЅОМАРТҮРЕ CTilePlotter::GetMapType(); 

T his returns the currently set map type for the potter. 


TILESIZE FUNCTIONS 


T here are three of these: one “setter” and two “getters.” T hese functions work with the iti leWidth and 
iTileHeight data members. 


void CTilePlotter::SetTileSize(int iTileWidth,int iTileHeight); 
T his sets a new tile width and tile height. It returns no value. 

int CTilePlotter::GetTileWidth(); 

T his returns the currently assigned tile width. 

int CTilePlotter::GetTileHeight(); 

T his returns the currently assigned tile height. 


PLOTTING FUNCTION 


T here is only one of these T he plotting function is the main purpose of the plotter. It uses the data 
members assigned to the plotter by the various set functions. 


POINT PlotTile(POINT ptMap); 


T his converts the position in ptMap into an appropriate world space coordinate. It returns the world space 
coordinate as a POINT. 
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USING CTILEPLOTTER 


T heres really not much to this: you declare the plotter, set it up, and you're ready to use it. CTilePlotter 
was intended to be used without dynamic allocation (that is, without the use of new), but nothing prevents 
you from using dynamic allocation to set up your plotter. | certainly dont mind. 


T he following code shows various snippets that you could use exactly as written (except for adjusting 
the width and height for your own particular tile size). It shows the setup for all four types of 
Supported maps. 


//////////////////////////////////////////////////////////// 

//declaration (all map types) 

CTilePlotter TilePlotter; 
//////////////////////////////////////////////////////////// 

//setup (slide) 

//////////////////////////////////////////////////////////// 
TilePlotter.SetMapType(ISOMAP SLIDE); 
TilePlotter.SetTileSize(64,32);//replace numbers with your actual tile sizes 
HII MB B MIB B IAT TTT TAT TT LLTI 

//setup (staggered) 
TilePlotter.SetMapType( ITSOMAP_STAGGERED) ; 
TilePlotter.SetTileSize(64,32);//replace numbers with your actual tile sizes 
//////////////////////////////////////////////////////////// 

//setup (diamond) 
TilePlotter.SetMapType(ISOMAP. DIAMOND) ; 
TilePlotter.SetTileSize(64,32);//replace numbers with your actual tile sizes 
ПИ ИИ ИИ 

//setup (rectangular) 
TilePlotter.SetMapType(ISOMAP. RECTANGULAR) ; 
TilePlotter.SetTileSize(64,32);//replace numbers with your actual tile sizes 
eee 

//use (all map types) 

POINT ptMap; 

POINT ptPlot; 

//MAPWIDTH/MAPHEIGHT are whatever numbers you are using for the size of your map 
for(ptMap.y=0;ptMap.y<MAPHEIGHT;ptMap.y++) 

{ 


is, 


for(ptMap.x=0;ptMap.x<MAPWIDTH; ptMap. x++) 
{ 
//plot the tile 
ptPlot=TilePlotter.PlotTile(ptMap) ; 
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//tile rendering code goes here 


} 


Pretty simple, right? Perhaps it's a little more involved than the little tileplotting functions used in earlier 
chapters, but the price of flexibility is a bit of complexity. 


TSOTILEWALKERH/ISOTILEWALKER СР 


T he files IsoT ileW alker.h and IsoT ileWalker.cpp contain the declarations and implementation required for 
the стітема1 кег Class, the declaration of which appears next. 


//typedef for a function pointer to a tilewalker function 
typedef POINT (*ISOHEXTILEWALKERFN) (POINT ptStart,ISODIRECTION IsoDirection); 
//tilewalker class 
class CTileWalker 
{ 
private: 
//tile walker function pointer 
ISOHEXTILEWALKERFN IsoHexTileWalkerFn; 
//iso map type 
ІЅОМАРТҮРЕ IsoMapType; 


public: 


//constructor 

CTileWalker(); 

//destructor 

~CTileWalker(); 

//map type 

void SetMapType(ISOMAPTYPE IsoMapType); 

ISOMAPTYPE GetMapType(); 

//tile walking 

POINT TileWalk(POINT ptStart,ISODIRECTION IsoDirection); 


Fr 


Just like with theT ileP lotter earlier, theT ileW alker component consists of two parts: a function pointer 
called TSOHEXTILEWALKERFN, and the CTileWalker Class itself. 


TSQHEXTILEWALKERFEFN 


| gave you the big talk about pointer functions during the discussion of theT ilePlotter, so 1711 spare you 
the pain of rehashing. АИТ ileWalker functions are required to look very similar to the function declara- 
tion shown next. A variable of the type 1SOHEXTILEWALKEREN points to a function like this: 
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POINT TileWalkerFunction(POINT ptStart,ISODIRECTION IsoDirection); 


T his function works just like the tilewalking functions seen in earlier chapters. Take a starting position 
(ptstart) and a direction (1soDirection, one of the 15001вЕСТІОМ values defined in IsoH ех efs.h), 
send them to this function, and it spits out whatever tile lies in that direction. T hisT ileW alker function 
works only for single steps, just as it did in earlier chapters, mainly because staggered maps make multistep 
tilewalking more difficult. 


IsoT ileW alker.cpp declares and implements four tilewalking functions— one for each of the supported 
map types. It would be a relatively small matter to make a new function that walked through another type 
of map if you needed one. 


PO soHex SlideTileWalk(POINT ptStart,ISODIRECTION IsoDirection);//slide walk- 
er 

POINT IsoHex_StagTileWalk(POINT ptStart,ISODIRECTION IsoDirection);//staggered 
walker 

POINT IsoHex DiamondTileWalk(POINT ptStart,ISODIRECTION IsoDirection);//diamond 
walker 

POINT IsoHex_RectTileWalk(POINT ptStart,ISODIRECTION IsoDirection);//rectangular 
walker 

T he names of the functions state their purposes pretty clearly, so | wont bother with a detailed 
explanation. 

CTILEWALKER 


T he other part of IsoT ileW alker.h/ IsoT ileW alker.cpp is the cTilewWalker Class itself. It is by far the 
simplest class in this engine, with only two data members and five member functions. 


DATA NEMBERS 


Table 15.4 lists cTi 1eWalker’s data members and briefly describes their purpose. ст11ема1 кег has only 
two data members. 


Table 15.4 CTileWalker Data Members 


Member Purpose 
IsoMapType Keeps track of the map type currently being used with this 
TileW alker 


IsoHexTileWalkerFn Contains a pointer to the function currently being used by the 
TileW alker to do its walking 
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The IsoMapType member is set with a call to CTileWalker::SetMapType and is retrieved with 
CTileWalker: :GetMapType. IsoHexTileWalkerFn is not a directly accessed data member. It is set from 
within the CTileWalker: :SetMapType function and is used by the cTileWalker: : Т11ема1 к function. 


MEMERER FUNCTIONS 


T here are five member functions in cTi1ewa1ker’s public section. T hey are listed in Table 15.5, along with 
a brief statement of thar purpose. Each member function is explained further after the table. 


Table 15.5 CTileWalker Member Functions 


Member Function Purpose 

CTileWalker() Constructor. Sets defaults. 

~CTileWalker() Destructor 

void SetMapType Assigns anew map type for the walker to work with 
(ISOMAPTYPE IsoMapType) 

ISOMAPTYPE GetMapType() Retrieves the currently assigned map type for the walker 
POINT TileWalker Performs a tile walk by taking a single step 


(POINT ptStart, 
ISODIRECTION IsoDirect) 


Each of these member functions deserves a sentence or two explaining how they work and what they do. 
CTileWalker::CTileWalker(); 


T his is cri 1eWalker'S constructor. It takes no parameters and returns no value. Since it is a construction, 
you never really call it directly anyway. It does only one thing— set the map type to 150МАР RECTANGULAR. 


CTileWalker::~CTileWalker(); 


T his is СТ11ема1 Кег5 destructor. It does even less than the constructor. In fact, this function is complete 
ly empty. 
void CTileWalker::SetMapType(ISOMAPTYPE IsoMapType); 


T his function sets up aT ileW alker to use a given map type. It also indirectly sets the function used by the 
T ileWalker to tile walk. Т his takes a parameter of the т50МАРТУРЕ and returns no value. 


ISOMAPTYPE CTileWalker::GetMapType(); 


T his returns an 150мАРТҮРҒ and takes no parameters. Т he return value contains the 150МАР_* value 
assigned in the last call to setMapType. 
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POINT CTileWalker::TileWalk(POINT ptStart,ISODIRECTION IsoDirection); 


T his function is the main purpose of CTileWalker. It takes a POINT parameter and an ISODIRECTION 
parameter, calls the function contained in IsoHexTileWalkFn, and returns the result of that function 
call (a POINT). 


USING CTILEWHALKER 


U sing cCTileWalker is sublimely easy. You declare it, set it up, and go. Т he following code shows you how 
to perform each of these tasks. You could copy these verbatim into a program that includes 
IsoT ileW alker.h/ IsoT ileWalker.cpp. 


ЛЛ MB MM MIEL B B Z C ÓP TP Bg B B BEP B P B CLIPLBGgMUMIIITP BG Jl] 
//Declaration 

CTileWalker TileWalker; 

LILIA LLIA AAAA AAAA E B MILL MB GIL Bg llli 
//Setting Up (Slide) 

TileWalker.SetMapType(ISOMAP SLIDE); 
//////////////////////////////////////////////////////////// 
//Setting Up (Staggered) 
TileWalker.SetMapType( ISOMAP_STAGGERED) ; 
//////////////////////////////////////////////////////////// 
//Setting Up (Diamond) 
TileWalker.SetMapType(ISOMAP DIAMOND); 
//////////////////////////////////////////////////////////// 
//Setting Up (Rectangular) 
TileWalker.SetMapType(ISOMAP RECTANGULAR) ; 
ПИ PP GMAIL P TATA AAI EAT 
//Use 
POINT ptStart;//starting point of the tile walker 

POINT ptNext;//destination of the tile walker 

ISODIRECTION idIsoDir;//direction of movement 
ptStart.x=STARTX;//replace STARTX with whatever x starts at 
ptStart.y=STARTY;//replace STARTY with whatever y starts at 
idIsoDir-ISODIR;//replace ISODIR with a suitable direction of movement 
ptNext-TileWalker.TileWalker(ptStart,idIsoDir);//plot the tile 


And that's about all there is to the стітемат кег Class. It is used later to help the смоизеМар dass do 
its job. T his class is the simplest of the bunch, as you probably can tell by the shortness of the section 
devoted to it. 
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TSOSCROLLER«H/ISOSCROLLER«wCPP 


Т hese files contain the declaration and implementation of the cscro11er dass, which is by far our 
largest class if you count by the number of member functions. Н еге are the declarations that appear in 
the header: 


//wrapping modes for anchors 
typedef enum 
{ 
RAPMODE_NONE,//no clipping of any kind is done to the anchor 
RAPMODE_CLIP, 
RAPMODE_WRAP 
} SCROLLERWRAPMODE ; 
//world space/screen space management class 
class CScroller 
{ 
private: 
//screen space 
RECT rcScreenSpace; 
//world space 
RECT rcWorldSpace; 
//anchor space 
RECT rcAnchorSpace; 
//anchor 
POINT ptScreenAnchor; 
//wrapmodes 
SCROLLERWRAPMODE swmHorizontal; 
SCROLLERWRAPMODE swmVertical; 
public: 
//constructor 
CScroller(); 
//destructor 
~CScroller(); 
//screen space 
RECT* GetScreenSpace(); 
void SetScreenSpace(RECT* prcNewScreenSpace); 
void AdjustScreenSpace(int iLeftAdjust,int iTopAdjust,int iRightAdjust, 
int iBottomAdjust); 
int GetScreenSpaceWidth(); 
int GetScreenSpaceHeight(); 
//world space 
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RECT* GetWorldSpace(); 

void SetWorldSpace(RECT* prcNewWorldSpace); 

void AdjustWorldSpace(int iLeftAdjust,int iTopAdjust,int iRightAdjust, int 
iBottomAdjust); 

int GetWorldSpaceWidth(); 

int GetWorldSpaceHeight(); 

//calculates worldspace based on a tile plotter, a tile extent rec- 
tangle, 
//and a map's height and width 

void CalcWorldSpace(CTilePlotter* TilePlotter,RECT* prcExtent, 
int iMapWidth,int iMapHeight); 

//anchor space 

RECT* GetAnchorSpace(); 

void SetAnchorSpace(RECT* prcNewAnchorSpace); 

void AdjustAnchorSpace(int iLeftAdjust,int iTopAdjust,int iRightAdjust, 
int iBottomAdjust); 

int GetAnchorSpaceWidth(); 

int GetAnchorSpaceHeight(); 

void CalcAnchorSpace();//calculates anchor space based on world space and 
Screen space 

//anchor 

POINT* GetAnchor(); 

void SetAnchor(POINT* pptNewAnchor,bool bWrap=true); 

void MoveAnchor(int iXAdjust,int iYAdjust,bool bWrap=true); 

void WrapAnchor();//applies clipping or wrapping to anchor 

/ [conversion 

POINT ScreenToWorld(POINT ptScreen); 

POINT WorldToScreen(POINT ptWorld); 

//wrap modes 

void SetHWrapMode( SCROLLERWRAPMODE ScrollerWrapMode) ; 

void SetVWrapMode( SCROLLERWRAPMODE ScrollerWrapMode); 

SCROLLERWRAPMODE SetHWrapMode(); 

SCROLLERWRAPMODE SetVWrapMode(); 

//validation 

bool IsWorldCoord(POINT ptWorld); 

bool IsScreenCoord(POINT ptScreen); 

bool IsAnchorCoord(POINT ptAnchor); 


}; 
| told you it was big. T he main thing I'd like to point out about this part of the engine is that it has 


almost nothing to do with isometric tiles, or even tiles at all. O nly a single member function even makes 
mention of tiles of any sort (CalcWor1dSpace).W ithout the Ca1cWor1dSpace function, this class would 
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still perform just fine. It can be used wherever scrolling is required. It is placed here amidst an isometric 
engine simply because scrolling is a very commonly needed component.T his part of the engine consists of 
two parts: SCROLLERWRAPMODE and CScroller. 


SCROLLERWRAPNMNODE 


T his is a little enumeration containing three values: wRAPMODE_NONE, WRAPMODE_CLIP, and 
WRAPMODE_WRAP. T hese values are used by cScroller to control how anchor space works. CScroller 
has one value for each axis so that they can be controlled separately. U sing wRAPMODE_NONE makes the 
axis unbound, and anchor space has no effect on the anchor. wRAPMODE_CLIP make the axis clipped to a 
given range. If a value is out of that range, wRAPMODE_CLIP sets it to the maximum or minimum value of 
that range. WRAPMODE_WRAP is for making cylindrical or torus maps. T he anchor moves from one edge to 
the other. 


CScROLLER 


Like my other classes, cScroller is divided into two areas: data members (private) and member 
functions (public). 


DATA NEMBERS 


Table 15.6 lists the cscro11er data members and briefly describes their purpose. Each one is explained 
more thoroughly after the table. 


Table 15.6 CScroller Data Members 


Member Purpose 

rcScreenSpace Stores a RECT that describes screen space 
rcWorldSpace Stores a RECT that describes world space 
rcAnchorSpace Stores a RECT that describes anchor space 
ptScreenAnchor A POINT representing the screen anchor 
swmHorizontal Controls the wrapping mode of the x-axis 


swmVertical Controls the wrapping mode of the y-axis 
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RCSCREENSPACE 


T his data member keeps track of where screen space is. It can be set to the same size as the screen itself, 
but it really has no limitations on what its size can be It is set with SetScreenSpace, retrieved with 
GetScreenSpace, and adjusted with AdjustScreenSpace. Т he width and height can be retrieved with 
GetScreenSpaceWidth and GetScreenSpaceHeight. 


RCWORLDSPACE 


T his data member keeps track of where world space is. U sually, it is calculated based on a tile plotter 
and a tile extent using Ca1cWor1dSpace. It can be set manually using SetWor1dSpace, retrieved with 
GetWorldSpace, and adjusted with AdjustWorldSpace.T he width and height can be retrieved with 

GetWorldSpaceWidth and GetWorldSpaceHeight. 


RCANCHORS PACE 


T his data member keeps track of where anchor space is. N ormally, it is calculated from world space 
and screen space by using CalcAnchorSpace, but it can be set manually by setAnchorSpace. It can be 
retrieved by GetAnchorSpace and adjusted by AdjustAnchorSpace.T he width and height are returned 
by GetAnchorSpaceWidth and GetAnchorSpaceHeight. 


PTSCREENANCHOR 


T his data member holds the screen anchor for the scroller. It can be set by а call to setAnchor. To retrieve 
it, use GetAnchor. Other member functions that work on ptscreenAnchor include MoveAnchor, Which 
changes the position of the anchor by relative amounts, and wrapAnchor, which applies the wrapping 
modes to x and y. 


SWMHORIZONTAL/S SWMVERTICAL 


T hese two data members contain the wrapping modes for the x- and y-axis, respectively. T hey may be 
assigned by using SetHWrapMode/ SetVWrapMode and retrieved by GetHWrapMode/ GetVWrapMode. 


Мем Ее FUNCTIONS 


T here аге a large number of these T hey were all listed a few pages back, and they are so numerous that | 
dont want to list them all again here. T hey are divided into several categories: Construction/ Destruction, 
Screen Space, World Space, Anchor Space, Anchor, Conversion, W rap M ode, and Validation. 


CONSTRUCTION/DESTRUCTION MEMBER FUNCTIONS 


T he constructor (cScroller()) doesnt do a whole lot. It sets all the various spaces to empty rectangles, 
sets the anchor to (0,0), and sets both the vertical and horizontal wrap modes to wRAPMODE_NONE.T he 
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destructor (-С$сго11ег()) does even less than the constructor. It's there simply because it is my 
custom to include a destructor, even if it isnt being used. U nless you dynamically allocate your scroller 
objects, you will not directly call either of these methods. 


SCREEN SPACE MEMBER FUNCTIONS 


Five screen space member functions perform all the necessary operations on the screen space rectangle 
(stored in rcScreenSpace). Each of these functions is listed and explained next. 


RECT* CScroller::GetScreenSpace(); 


T his member function takes no parameters and returns a pointer to rcScreenSpace. Since this is a 
pointer, and not а const pointer or a const reference, you can access (and modify) the members of 
rcScreenSpace through the use of this function. You might not want to do that, though. | thought it 
would be fair to warn you. 


void CScroller::SetScreenSpace(RECT* prcNewScreenSpace); 


T his function takes a pointer to a RECT and returns no value. It copies the RECT pointed to by 
prcNewScreenSpace and copies it member-for-member into rcScreenSpace. For the most part, you 
would use this function a single time in a program and never need to call it again. 


void CScroller::AdjustScreenSpace(int iLeftAdjust,int iTopAdjust,int 
iRightAdjust, int iBottomAdjust); 


If you need to be able to adjust the screen space on-the-fly, this function does that for you. It takes four 
int parameters and returns no value. W hen this function is called, it adds the appropriate parameter to the 
corresponding rcScreenSpace member. For example, i LeftAdjust is added to rcScreenSpace. left. 


int CScroller::GetScreenSpaceWidth(); 


T his function has no parameters and returns an integer. T his returned value is the difference between 
rcScreenSpace’s right and left members. 


int CScroller::GetScreenSpaceHeight(); 


T his function has no parameters and returns an integer. T his returned value is the difference between 
rcScreenSpace’s bottom and top members. 


WORLD SPACE MEMBER FUNCTIONS 


T here are six of these, and the first five of them correspond to a similar function that deals with screen 
space. Т hese functions all affect гсиог1 аѕрасе. 


RECT* CScroller::GetWorldSpace(); 


T his corresponds to GetScreenSpace. It takes no parameter and returns a pointer to rcWor1dSpace.T his 
function can be used to change the values within rcWor1dSpace. 


void CScroller::SetWorldSpace(RECT* prcNewWorldSpace); 


T his corresponds to setScreenSpace. It takes a pointer to a кест and returns no value. It copies the 
RECT pointed to by prcNewWorldSpace into rcWorldSpace. 
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void CScroller::AdjustWorldSpace(int iLeftAdjust,int iTopAdjust,int iRightAdjust, 
int iBottomAdjust); 


T his corresponds to AdjustScreenSpace. It has no return value and four int parameters. It adds the 
appropriate parameter to the corresponding member of rcwWor1dSpace. 


int CScroller::GetWorldSpaceWidth(); 


T his corresponds to GetScreenSpaceWidth. It takes no parameters and returns the difference between 
rcWor1dSpace' right and left members. 


int CScroller::GetWorldSpaceHeight(); 


T his corresponds to GetscreenSpaceHeight. It takes no parameters and returns the difference between 
rcWorldSpace’s bottom and top members 


void CScroller::CalcWorldSpace(CTilePlotter* TilePlotter,RECT* prcExtent,int 
iMapWidth,int iMapHeight); 


T his member function is unique to the world space category. Given aT ilePlotter pointer (Ti1ePlotter), 
a pointer to a кест that contains the average tiles extent (prcExtent), and the width and height of the 
етар (:MapWidth and iMapHeight), this function calculates the coordinates that define world space. 


ANCHOR SPACE 


T here are six of these. T he first five correspond to similar screen space member functions. T he last one 
assists in anchor space calculation. 


RECT* CScroller::GetAnchorSpace() ; 


T his corresponds to GetScreenSpace. It returns a pointer to the rcAnchorSpace data member. T his 
function can be used to directly access or modify the members of rcAnchorSpace. It takes no parameters 
and returns a RECT pointer. 


void CScroller::SetAnchorSpace(RECT* prcNewAnchorSpace) ; 


T his corresponds to SetScreenSpace. It copies the RECT pointed to by prcNewAnchorSpace into 
rcAnchorSpace. It takes a RECT pointer parameter and returns no value. 


void CScroller::AdjustAnchorSpace(int iLeftAdjust,int iTopAdjust,int 
iRightAdjust, int iBottomAdjust); 


T his corresponds to AdjustScreenSpace. It takes four int parameters and returns no value. Each mem- 
ber of rcAnchorSpace 15 adjusted by the appropriate parameter. 


int CScroller::GetAnchorSpaceWidth(); 


T his corresponds to GetScreenSpaceWidth. It takes no parameters and returns an int. T he returned 
value is the difference between rcAnchorSpace’s right and left members. 


int CScroller::GetAnchorSpaceHeight() ; 
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T his corresponds to GetScreenSpaceHeight. It takes no parameters and returns an int. T he returned 
value is the difference between rcAnchorSpace's bottom and top members. 


void CScroller::CalcAnchorSpace(); 


T his member function is unique to the anchor space functions. Based on the current world space and 
screen space (and the two wrap modes), the anchor space is calculated. T he screen spaces width and/ ог 
height are subtracted whenever the horizontal and vertical wrap modes are not WRAPMODE WRAP. 


ANCHOR MEMBER FUNCTIONS 


T he four anchor functions deal with the manipulation of the anchor itself. T hey affect the values of 
ptScreenAnchor. 


POINT* CScroller::GetAnchor(); 


T his function returns a pointer to ptscreenAnchor. U sing this function, you can change the values of 
your anchor to outside of the valid range. T his takes no value and returns a POINT pointer. 


void CScroller::SetAnchor(POINT* pptNewAnchor,bool bWrap); 


T his function takes a POINT pointer and an optional boo! pointer. It returns no value. 
T he ptScreenAnchor data member's x and y are copied from those pointed to by pptNewAnchor. 
If bWrap is true, the scroller calls wrapAnchor immediately afterward. 


void CScroller::MoveAnchor(int iXAdjust,int iYAdjust,bool bWrap); 


T his member function takes two int parameters and an optional роот parameter. It returns no value. 
T he ixadjust and ivAdjust parameters are added to рі5сгеепАпсһог5 x and y members. If burap 15 
true, WrapAnchor is immediately called afterwards. 


void CScroller::WrapAnchor(); 


T his function takes no parameter and returns no value. D epending on the horizontal and vertical wrap 
modes, it performs different operations on ptscreenAnchor. 


If an axis has wRAPMODE. NONE, no range checking is performed. If an axis has wRAPMODE_CLIP, the anchor 
is dipped to the nearest point in the range. If the axis has uRAPMODE, WRAP, either the anchor spaces width 
or height are subtracted from or added to the anchor until it lies within the range. 


CONVERSION NIEMBER FUNCTIONS 


After you set up the various spaces, these two functions, along with MoveAnchor, are the most commonly 
used. T hey translate between coordinate sets (namely, world space and screen space). 


POINT CScroller::ScreenToWorld(POINT ptScreen); 


T his function takes a POINT and returns a POINT. T he ptScreen parameter is a screen coordinate, and the 
returned value represents the corresponding world space coordinate. T his function is helpful to use with a 
M ouseM ap, since the first step of mousemapping is the conversion from screen to world. 
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POINT CScroller::WorldToScreen(POINT ptWorld); 


T his function takes a POINT and returns a POINT. T he ptWor1d parameter is a world coordinate, and the 
returned value represents the corresponding screen space coordinate. T his function is helpful to use with a 
T ilePlotter, because theT ilePlotter spits out world coordinates, and those need to be converted into screen 
coordinates. 


WRAP MODE MEMBER FUNCTIONS 


T hese four functions either get or set the two wrapping modes for the scroller. | abbreviated horizontal 
and vertical to H and V in these functions— mainly to save myself some typing. 


void CScroller::SetHWrapMode(SCROLLERWRAPMODE ScrollerWrapMode); 


T his takes a SCROLLERWRAPMODE parameter and returns no value. It sets a new value to swmHorizontal. 
T his value controls how the x value of the anchor is treated in calls to WrapAnchor. 


void CScroller::SetVWrapMode(SCROLLERWRAPMODE ScrollerWrapMode); 


T his takes a SCROLLERWRAPMODE parameter and returns no value. It sets а new value to swmVertical. 
T his value controls how the y value of the anchor is treated in calls to wrapAnchor. 


SCROLLERWRAPMODE CScroller::GetHWrapMode(); 

T his takes no parameter and returns a SCROLLERWRAPMODE. It retrieves the value of swmHorizontal. 
SCROLLERWRAPMODE CScroller::GetVWrapMode(); 

T his takes no parameter and returns а SCROLLERWRAPMODE. It retrieves the value of swmVertical., 


VALIDATION MIEMBER FUNCTIONS 


T hese three functions arent absolutely necessary for the scroller to function. T hey are provided mainly for 
utility, because code using the existing member functions and a вЕСТ function would be longer. Each of 
these functions checks to see if a given POINT lies within that spaces RECT. 


bool CScroller::IsWorldCoord(POINT ptWorld); 


T his takes a POINT parameter and returns а роот. If ремогта lies within world space, the return value is 
true. If not, the return value is false. 


bool CScroller::IsScreenCoord(POINT ptScreen); 


T his takes a POINT parameter and returns a boo1. If ptScreen lies within screen space, the return value is 
true. If not, the return value is false. 


bool CScroller::IsAnchorCoord(POINT ptAnchor); 


T his takes a POINT parameter and returns a boo1. If ptAnchor lies within anchor space, the return value is 
true. If not, the return value is false. 
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USING CSCROLLER 


T he beauty of сѕсготтег is that it doesnt have to be tied to any particular type of map, so it has no 
150МАРТҮРЕ member. Н owever, using it properly with one of your map types requires world space to be 
calculated (unless, of course, you want to do it on your own). T his requires that you set up aT ilePlotter 
prior to setting up your scroller. T he following are some snippets of code that demonstrate how to make 
use of а scroller: 


ИИ ИИ ИИ | 
//declaration 
CScroller Scroller; 
ИИ TT TTT 
//setup 
SetRect(Scroller.GetScreenSpace(),0,0,640,480);//this will set up 
//a screen space for the 


entire 

// screen in a 640x480 dis- 
play 
Scroller.SetHWrapMode(WRAPMODE_CLIP);//set up clipping for the anchor 
Scroller.SetVWrapMode(WRAPMODE CLIP); 
//TilePlotter is a preexisting tile plotter object 
//rcExtent is a RECT containing a tile extent, usually from a TileSet 
//MAPWIDTH and MAPHEIGHT contain the width and height of the tilemap 
Scroller.CalcWorldSpace(&TilePlotter,&rcExtent ,MAPWIDTH,MAPHEIGHT) ; 
Scroller.CalcAnchorSpace();//calculate the anchor space 
ИИ TTT TTT TAT TTT 
//moving the anchor about 
Scroller.MoveAnchor(dx,dy);//dx and dy are values you wish to scroll by 


As you can see, despite the rather large size of the cScro11er Class, its use is pretty easy. In addition, 


it makes scrolling a snap. If you were ever trapped on a desert island, and you could have only a single class 
with you, CScro11er would be the best one to pick. 


TSOMo0usEM APAH/ISOMoOuUsSEMAPECRrP 


T heses files contain the declarations and implementation required for the смоизеМар Class. Of all the 
components, this one changed the least since its last form. It relies on the use of aT ileWalker and a 
scroller, although this is not an absolute requirement. (Id be interested to see a solution that didnt 
require at least one of the other components.) 


//mousemap directions 
typedef enum { 
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БЕ 
NW 
| NE 
|_ SW 
ESSE 


NTER=0, 


=1, 
=2, 
=3, 
=4 


} MOUSEMAPDIRECTION; 
//mousemap class 
class CMouseMap 


{ 

private: 
//wid 
int 1 
int 1 
//ref 
POINT 
//loo 
MOUSE 
//scr 
CScro 
//wal 
CTile 

public: 
//con 
CMous 
//des 
~CMou 
//Тоа 
void 
void 
//des 
void 
//wid 


th and height of lookup 

idth; 

Height; 

erence point (adjustment for the upper left of tile 0,0) 
ptRef; 

up table 

APDIRECTION* mmdLookUp; 

oller 

ller* pScroller; 

er 
alker* pTileWalker; 


structor 

eMap(); 

tructor 

seMap(); 

d mousemap 

Load(LPCTSTR lpszFileName);//used with iso and hex maps 
Create(int iWidth,int iHeight);//used with rectangular maps 
troy mousemap 

Destroy 
th/height 


w 


int GetWidth(); 
int GetHeight(); 


//ref 


erence 


POINT* GetReferencePoint(); 


void 
void 
/ /map 
POINT 
//scr 
CScro 


SetReferencePoint(POINT* pptRefPt) ; 
CalcReferencePoint(CTilePlotter* pTilePlotter,RECT* prcExtent); 
the mouse 
MapMouse(POINT ptMouse); 

oller 

ller* GetScroller(); 
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void SetScroller(CScroller* pScroller); 
//walker 

CTileWalker* GetTileWalker(); 

void SetTileWalker(CTileWalker* pTileWalker); 


E 
M uch like the rest of the components, 150М ouseM ap.h and 150М ouseM ap.cpp are divided into two main 
declarations: MOUSEMAPDIRECTION and CMouseMap Class. l'Il explain each. 


MOUSENAPDIRECTION 


T his enumerated type corresponds exactly to the MouseMapDirection enumerated types used in Chapters 
12 through 14.T he only real difference is that the name is now in all capital letters. T he value MM CENTER 
represents the centered tile of the map. MM NE, MM SE, MM NW, and MM sw represent the corners of the 
lookup. [п case you need a refresher, Figure 15.3 shows what I’m talking about. 


Figure 15.3 


A M ouseM ap and its 
MOUSEMAPDIRECTIONS 


CIYloussrYimrz 


Like with all the components so far, | decided to implement the M ouseM ap as a class. Also, just like all 
the other classes, it is divided into a private data section and a public member function section. смоизеМар 
is the final piece of the puzzle Two of the other components— namely, theT ileW alker and the scroller 
fit nicely into it. Similarly, the M ouseM ap fits nicely into theT ilePlotter, which we will examine later. 


DATA NEMBERS 


CMouseMap has six data members. Т hey cover a hodgepodge of data, from the size of the map to what 
scroller and T ileWalker to use Table 15.7 lists and briefly explains these data members. 
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Table 15.7 CMouseMap Data Members 


Data Member Meaning 

iWidth W idth of the MouseMap 

iHeight Height of the MouseMap 

ptRef Reference point for measuring relative to tile (0,0) 

mmd LookUp The actual MouseMap lookup array 

pScroller A pointer to the scroller to use for converting screen space to 
world space 

pTileWalker A pointer to theTileW alker used for converting MouseM ap 


coordinates to map coordinates 


MEMRER FUNCTIONS 


T he member functions for CM ouseM ap are presented in groups of related functions, so that you dont 
have to look upon them as a big lump. 


CONSTRUCTION/DESTRUCTION MEMBER FUNCTIONS 

T he constructor and destructor dont really do much for the M ouseM ap. T he constructor creates a default 
1х1 M ouseM ap so that if for some reason you use your M ouseM ap before using Load Or Create, at least 
you wont get division by 0. 

CMouseMap: : CMouseMap() ; 

T his creates a default 1x1 tilemap. 

СМоизеМар::-СМоизеМар(); 


T his destroys whatever M ouseM ap is currently loaded. (T his means you dont have to explicitly call 
Destroy at the end of a program that uses cMouseMap.) 


LOOKUP TABLE MEMBER FUNCTIONS 


| needed to have some way to load bitmaps into my смоиземар Class, but | also needed a way to create my 
own arbitrarily sized M ouseM aps that initially are filled with Мм cENTER but that can be filled with what- 
ever values | like. T hese three functions аге what | came up with. 


void CMouseMap::Load(LPCTSTR lpszFileName); 


T his function is used to load the bitmap specified by its 1pszFileName parameter. T he image in question 
is loaded and parsed into a lookup table. It returns no value. 
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void CMouseMap::Create(int iWidth,int iHeight); 


T his function creates an arbitrarily sized lookup table, the dimensions of which are specified by the 
iWidth and iHeight parameters. Т he lookup table is allocated and filled with the value мм_СЕМТЕВ. 
Use this function either for a rectangular M ouseM ap or for some other axonometric M ouseM ap that 
needs а user-supplied lookup table. 


void CMouseMap: :Destroy(); 


T his function deallocates the lookup table. It is called by the destructor, so you dont ever have to 
actually call it. 


TILE Size MEMBER FUNCTIONS 


O nce the mouse map is loaded/ created, you need some way to get the size of the М ouseM ap, so | ve 
provided two functions. 


int CMouseMap::GetWidth(); 

Returns the width of the M ouseM ap. It takes no parameters. 
int CMouseMap::GetHeight(); 

Returns the haght of the М ouseM ap. It takes no parameters. 


REFERENCE POINT MEMBER FUNCTIONS 


You remember our nice talk about the reference point, right?T he one about how you have to match up 
the corners of the M ouseM ap with tile (0,0) and how that value isnt necessarily world space (0,0)?T hat's 
what these functions help you with. 


POINT* CMouseMap::GetReferencePoint(); 
T his retrieves the reference point. It takes no parameters and returns a pointer to a POINT. 
void CMouseMap::SetReferencePoint(POINT* pptRefPt); 


T his copies a point into the reference point. It takes a POINT pointer that points to the PoINT you want to 
copy. Returns no value. 


void CMouseMap::CalcReferencePoint(CTilePlotter* pTilePlotter,RECT* prcExtent); 


M ost of the time, you will use this function to set up your reference point. Based on a tile plotter (pointed 
to by the pritePlotter parameter) and an extent rectangle (pointed to by prcExtent), the reference 
point is calculated. 


SCROLLER MEMBER FUNCTIONS 


Unless your world space and screen space are the same, which usually isnt so, you'll need to plug a scroller 
into your M ouseM ap so that it can do your screen-to-world calculation. 
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CScroller* CMouseMap::GetScroller(); 


T his retrieves the scroller that is currently being used by the М ouseM ар. It takes no parameters and 
returns a pointer to a С$сго11ег. 


void CMouseMap::SetScroller(CScroller* pScroller); 


T his sets a new scroller to be used with the М ouseM ap. It takes a pointer to a CScro11er and returns 
no value. 


TILEWALKER MEMBER FUNCTIONS 

T he M ouseM ар, in addition to a scroller, needs aT ileWalker to perform its job properly. T hese functions 
get or set a pointer to aT ileW alker for the М ouseM ap to use. 

CTileWalker* CMouseMap::GetTileWalker(); 

T his retrieves the pointer to theT ileWalker that the M ouseM ap is using. 

void CMouseMap::SetTileWalker(CTileWalker* pTileWalker); 

T his sets a new pointer to aT ileW alker for the M ouseM ар to use 


Mouse MAPPING FUNCTION 


And last, but certainly not least, the main working function of the cMouseMap Class. It has fewer 
parameters than the M ouseM aps used in Chapters 12 through 14, since the class itself stores the needed 
extra information. 


POINT CMouseMap::MapMouse(POINT ptMouse); 


T his takes the screen coordinate contained by the ptMouse parameter, converts it into a map coordinate, 
and returns that coordinate. 


Мелмоа CTlYloussrvrinmrzge 


T he смоиѕемар dass is easy to set up and use. Т he following code snippets show how the most common 
tasks, like declaration, setup and use are done. 


//////////////////////////////////////////////////////////// 
//declaration 

CMouseMap MouseMap; 
//////////////////////////////////////////////////////////// 

//setup 

MouseMap.Load("mousemap.bmp");//mousemap.bmp contains the proper image. 
MouseMap.SetScroller(&Scroller);//Scroller is a CScroller object 
MouseMap.SetTileWalker(&TileWalker);//TileWalker is а CTileWalker object 
//////////////////////////////////////////////////////////// 
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//use 
POINT ptMap=MouseMap.MapMouse(ptMouse);//ptMouse is a screen 
//coordinate of the mouse 


158o0HgxCOorÓtEeEaH 


Because each of the four components (T ileP lotter, T ileW alker, Scroller, and M ouseM ap) is in a separate 
header/ cpp file, to make use of them you would need to include all the headers into your program. 
IsoH exCoreh removes that requirement by including all the headers for you in a single header file. 


T here you have it— a complete isometric engine. Yes, you still have much work to do before it's actually 
game-worthy, but you have a solid foundation on which you can build. 


AN ISOHEXCORE EXAMPLE 


N ow that all the explanations for these classes are done, let's make a sample program. Load up 

IsoH ех15 L.cpp.T his example demonstrates the true flexibility of the soH exC ore engine. It can switch 
from one type of tilemap to another while the application is still running. IsoH ех15 1 is based on 

ISOH ех1 1.срр. It uses most of the files you are accustomed to using— namely, 

GD ICanvas.h/ GD I Canvas.cpp, D DFuncs.h/ D D Funcs.cpp, and T ileSet.h/ T ileSet.cpp. In addition, it 
brings in thelsoH exCore engine files weve been exploring in this chapter. 


Figures 15.4, 15.5, and 15.6 show the three faces of this application. By pressing the 1, 2, or 3 key, you 
can instantly change what map type is being used, and the scroller will be recalculated so that you can 
maneuver around just like in some of the earlier chapters’ examples. It's like three programs in one! 


Figure 15.4 


The result of pressing 
the 1 key 
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Figure 15.5 


The result of pressing the 
2 key 


Figure 15.6 


The result of pressing the 
3 key 


GLOSALS 


M ost of the globals listed next are self-explanatory and/ or you've used them before Т hey cover everything 
from your basic D irectD raw objects, to your tilesets, to your new iso engine components. 

//directdraw 

LPDIRECTDRAW7 lpdd-NULL; 

LPDIRECTDRAWSURFACE7 lpddsMain-NULL; 
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LPDIRECTDRAWSURFACE7 1lpddsBack=NULL; 
LPDIRECTDRAWCLIPPER lpddClipzNULL; 
//tilesets 

CTileSet tsIso;//main tileset 

CTileSet tsCursor;//cursor 

//isohexcore components 

CTilePlotter TilePlotter;//plotter 
CTileWalker TileWalker;//walker 

CScroller Scroller;//scroller 

CMouseMap MouseMap;//mousemap 

POINT ptCursor;//keep track of the cursor 
POINT ptScroll;//keep track of how quickly we scroll 
int iMapLMAPWIDTH]LMAPHEIGHT];//map array 


See? № othing really new, except for the iso engine components, ri 1ePlotter, Ti leWalker, Scroller, and 
MouseMap. IS this seaming too easy to you? It sure is to me! (T hat's not a bad thing, though. Easy is good.) 


INITIALIZATION AND CLEANUP 


| wanted to cover the beginning and end of the program together, since they are related. T he cool thing 
about 150Н exCore is that none of the components have to be dynamically allocated with new, which 
means you dont have to deallocate them later with delete, and they will automatically be destroyed 
when they go out of scope (when the program ends). T his frees you a great deal in your cleanup code. 


First, les take a look inside Prog Init, where you set everything up. T his first part you should already 
be familiar with, because it sets up your basic D irectD raw objects. 


//DirectDraw Initialization 

//create IDirectDraw object 

lpdd-LPDD, Create(hWndMain,DDSCL EXCLUSIVE | 
DDSCL FULLSCREEN | DDSCL ALLOWREBOOT); 
//set display mode 
lpdd-»SetDisplayMode(640,480,16,0,0); 
//create primary surface 

lpddsMain-LPDDS СгеатеРгітагу(1р4а,1); 

//get back buffer 
lpddsBack=LPDDS_GetSecondary(1pddsMain); 
//create clipper 
lpdd->CreateClipper(0,&lpddClip,NULL); 
//associate window with the clipper 
lpddClip-»SetHWnd(O,hWndMain); 
//attach clipper to back buffer 
lpddsBack->SetClipper(lpddClip); 
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N othing too hard, right? N ext, you start to initialize your 150Н exC ore components. Pay attention to the 
order in which I'm doing this, because it may seem a little weird. 


First, partially initialize the M ouseM ap by telling it to load the image from which it scans the 
lookup table. 


//Лоаа in the mousemap 
MouseMap.Load("MouseMap.bmp"); 


N ext, set up theT ilePlotter, even though you arent yet done setting up the M ouseM ap. Told you it was 
weird. Set theT ilePlotter's map type (on initially loading, you set it to ISOMAP_DIAMOND), and set the 
width and height for the tileplotting calculations. You get this width and height from the M ouseM ap. 
Aha!T hat's why you load the М ouseM ap first, and it also explains why you dont just have a single func- 
tion that you call to initialize your M ouseM ap. 


//set up the tile plotter 

TilePlotter.SetMapType(ISOMAP DIAMOND);//diamond mode 

TilePlotter.SetTileSize(MouseMap.GetWidth(), 
MouseMap.GetHeight());//grab width and height from mousemap 


You dont have to touch пет ilePlotter again, so move on to {пет ileW alker. T пет ileW alker 


could have been initialized earlier, but this was just the place | chose to do it. Set the map type 
to 150МАР DIAMOND and be done with {пет ileW alker. 


//set up tile walker to diamond mode 
TileWalker.SetMapType(ISOMAP DIAMOND); 


Time for the scroller. Т he scroller's initialization is probably the longest and most involved part of 
IsoH exCore initialization. First, set up a ВЕСТ that has the same dimensions as the screen. 


//set up screeen space 

RECT rcTemp; 
SetRect(&rcTemp,0,0,640,480) ; 
Scroller.SetScreenSpace(&rcTemp) ; 


N ow you have to load in your tilesets. W hat? But you havent finished setting up the scroller! W ell, you 
need the tile extent to calculate world space, so you need to have the tilesets loaded. In the end, theonly 
thing that matters is that everything gets loaded properly and nothing gets left behind. So, as | was saying, 
load in the tilesets. 


//Тоаа in tiles and cursor 
tsIso.Load(lpdd,"Tiles.bmp"); 
tsCursor.Load(l1pdd,"cursor.bmp") ; 
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Grab the tile extent вест from the first tile of ts Iso. You could have picked any of the tiles, because they 
all have the same dimensions. O nce you have the extent send it, a pointer to theT ileP lotter, and the width 
and height of the map to calculate the scroller’s world space. 


//grab tile extent from tileset 

CopyRect(&rcTemp, &tsIso.GetTileList()L0].rcDstExt); 

//calculate the worldspace 
Scroller.CalcWorldSpace(&TilePlotter,&rcTemp,MAPWIDTH,MAPHEIGHT) ; 


Back to the М ouseM ар. U setheT ilePlotter and the extent вест to calculate the reference point for the 
M ouseM ap. H onestly, you could have waited, but | like having all the code dealing with the tile extent 
RECT in one area rather than spread out all over the place, making it necessary to scroll up and down to 
look for it if something went wrong. 


//calculate the mousemap reference point 
MouseMap.CalcReferencePoint(&lilePlotter,&rcTemp) ; 


N ow finalize the scroller initialization. First, set the horizontal and vertical wrap modes (both of them are 
WRAPMODE_CLIP).T hen calculate the anchor space, and finally set the scroller’s anchor to (0,0). 


//set wrap modes for scroller 
Scroller.SetHWrapMode(WRAPMODE CLIP); 
Scroller.SetVWrapMode(WRAPMODE CLIP); 
//calculate anchor space 
Scroller.CalcAnchorSpace(); 

//set scroller anchor to (0,0) 
Scroller.GetAnchor()-»x-0; 
Scroller.GetAnchor()->y=0; 


At last, finish what you started by attaching the scroller and theT ileW alker to the M ouseM ap, and you 
have successfully wrapped up your 150Н ехСоге initialization. 


//attach scroller and tilewalker to mousemap 
MouseMap.SetScroller(&Scroller); 
MouseMap.SetTileWalker(&TileWalker); 


Finally, set up a random map, and return true. 


//set up the map to a random tilefield 
for(int x-0;x«MAPWIDTH; х++) 
{ 


for(int y=0;y<MAPHEIGHT; у++) 
{ 


ISOMETRIC GAME PROGRAMMING ulrH DIRECTX 7,0 


iMapLx]Ly]=rand()%tsIso.GetTileCount(); 


| 
return(true);//return success 

T he Prog_Done function isn't nearly the size of Prog_Init, Since you only have to clean up the 
D irectD raw objects. 


void Prog Done() 

{ 
//release main/back surfaces 
LPDDS_Release(&lpddsMain) ; 
//release clipper 
LPDDCLIP_Release(&lpddClip); 
//release directdraw 
LPDD_Release(&lpdd); 


} 


N ot much to it. It’s really cool that you don't have to jump through elaborate hoops in order to get rid 
of your iso engine components. T hey practically clean themselves up. 


MAIN LOOF 


T he main loop can be broken into four major steps: clear back buffer, draw tilemap, draw cursor, and flip. 
All of this code is іп Prog Loop. 


T his first snippet clears out the back buffer by setting up a оовітех structure. You've seen this before, so | 
won't say any more. 


//clear out backbuffer 

DDBLTFX ddbitfx; 

DDBLTFX ColorFill(&ddbltfx,0); 
lpddsBack-»Blt(NULL,NULL,NULL,DDBLT WAIT | DDBLT COLORFILL,&ddbltfx); 


N ow, update the scroller's anchor by moving the anchor in accordance with the values stored in ptscro11. 
T he manner in which ptScro11 is assigned these values can be found later іп the "Event Н andling" sec- 
tion. 


//move the anchor based on scrolling speed 
Scroller.MoveAnchor(ptScroll.x,ptScroll.y); 


Time to plot your tiles. Loop through the map coordinates using a POINT variable румар. For each map 
position, plot the tile using your T ilePlotter and then convert that point from world to screen coordinates 
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using the scroller. Always remember that aT ileP lotter outputs world coordinates only, and you need the 
plotter to translate to screen coordinates. After the world-to-screen conversion, simply put the tile with the 
tiles tsIso. 


//plot our tiles 

POINT ptPlot; 

POINT ptMap; 
for(ptMap.y=0;ptMap.y<MAPHEIGHT;ptMap.y++) 
{ 


for(ptMap.x=0;ptMap.x<MAPWIDTH; ptMap. x++) 
{ 
//plot the tile 
ptPlot-TilePlotter.PlotTile(ptMap); 
//convert from world to screen 
ptPlot=Scroller.WorldToScreen(ptPlot) ; 
//put the tile 
tsIso.PutTile(lpddsBack,ptPlot.x,ptPlot.y,iMapLptMap.xJ[ptMap.y]); 


} 


N ext, grab the mouse’ current position using theW IN 32 function GetCursorPos. | havent covered this 
function in any of our discussions, but it's pretty simple. Pass a pointer to a POINT to be filled with the 
mouses current position. Alternatively, | could have stored the value of the current mouse position during 
the WindowProc’s WM_MOUSEMOVE message handler, but this way works just as well. 


//grab the mouse position 
POINT ptMouse; 
GetCursorPos(&ptMouse) ; 


Because you have the mouse position now, you can go ahead and use the M ouseM ap to figure out what tile 
you are on and store that position in ptCursor (which, if you look back, is your global variable for storing 
the cursor position). 


//map the mouse 
ptCursor=MouseMap.MapMouse(ptMouse) ; 


№ aturally, your M ouseM ap doesnt know how big your map is, so you have to clip it to valid map squares 
by yourself. T hat is what this next bit does. 


//clip the cursor to valid map coordinates 
if(ptCursor.x«0) ptCursor.x=0; 

if(ptCursor.y«0) ptCursor.y=0; 
if(ptCursor.x>(MAPWIDTH-1)) ptCursor.x=MAPWIDTH-1; 
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if(ptCursor.y>(MAPHEIGHT-1)) ptCursor.y=MAPHEIGHT-1; 


So, you've got a mousemapped and validated cursor position. All that is left to do is plot the darn thing. 
First, you have to use theT ilePlotter to calculate its world position, and then the scroller to convert that 
to a screen position, and finally the tileset to blit the cursor. 


//plot the cursor 
ptPlot=TilePlotter.PlotTile(ptCursor); 

//convert world to screen 
ptPlot=Scroller.WorldToScreen(ptPlot); 

//put the cursor on screen 
tsCursor.PutTile(lpddsBack,ptPlot.x,ptPlot.y,0); 


Oh, yes... and flip the primary surface. 


//flip to show the back buffer 
lpddsMain-»Flip(O,DDFLIP WAIT); 


T his function is a good place to see all the IsoH exC ore components in action. All four аге used here. 
(T heT ileW alker is not explicitly used, but the M ouseM ap makes use of it.) You'll notice that most of 
the lines in the Prog. Loop function call one of the engine components, and you can see how very little 
you do yourself, 


EVENT HANDLING 


Youre in the home stretch now. 150Н ех15 1.срр responds to two messages (at least as far as user interac- 
tion is concerned)— WM_KEYDOWN and wm_MOUSEMOVE. W ell take wM_MOUSEMOVE first, because it's shorter. 


Т he only purpose of the wm_mousemove handler is to figure out if you intend to scroll and if you do, by 
how much. You've seen code similar to this in prior chapters examples. № othing really new here. 


case WM_MOUSEMOVE: 
{ 

//grab mouse x and y 
int x=LOWORD(1Param) ; 
int y=HIWORD(1Param); 
//reset scrolling speeds to zero 
ptScrol1l.x=0; 
ptScroll.y=0; 
//left scroll? 
if(x<8) ptScroll.x=x-8; 
//upward scroll? 
if(y<8) ptScroll.y=y-8; 
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//right scroll? 
if (x>=632) ptScroll.x=x-632; 
//downward scroll? 


if(y>=472) ptScroll.y=y-472; 


}break; 


In the им кеүроим handler you do something else entirely— namely, reconfigure the entire 150Н exCore 
engine to work with another map type. First, the им. кеүромм handler does a switch based 


on the value of wParam 
window to dose, which 


(which contains the virtual key code). If thevalueis vk, Escape, it tels the main 
then exits the program. If the value is 1, 2, or 3, it goes to short bits of code that 


reinitialize the iso engine components. I'll only show the code for if 1 is pressed, because 2 and 3 are very 
similar. (Just replace the instances of I1SOMAP_SLIDE With ISOMAP_STAGGERED OF ISOMAP. DIAMOND.) 


case ‘1’: 
{ 


//set up the iso engine for slide maps 


Tile 


Scroller.CalcWorld 


Scrol 


//set 


Scrol 


Scrol 
}break; 


alker.SetMapType(ISOMAP SLIDE);//set walker to slide mapping 


TilePlotter.SetMapType(ISOMAP SLIDE);//set plotter to slide mapping 
//recalculate the scroller 


Space(&TilePlotter,&tsIso.GetTileList()[0].rcDstExt, 
MAPWIDTH,MAPHEIGHT); 
ler.CalcAnchorSpace(); 
the screen anchor back to zero 
ler.GetAnchor()->x=0; 
ler.GetAnchor()->y=0; 


As you can see, you don't have to go through all the rigmarole that you had to during Prog_Init, because 
the main part of the iso engine doesnt change. Y ou simply have to change the map type for the plotter and 
walker and recalculate the world and anchor spaces for the scroller. N othing to it! And you can look at the 
other map types; they have virtually the exact same code. 


SuNMmMAR 


Y 


Wow. T he end of the chapter (and you thought it would never соте). Also, the end of the part on isohex 
basics. You've learned about tiles, about what tile based means, and about the three isometric map types. 
You now have a solid engine core to work with. Seems like it's been light-years since Part 1. O f course, at 
the end of the next part, it'll seem like you've progressed light-years ahead of where you are now. Finally, 


you're going to get into 


some real stuff. You've done enough "random tilemap" examples. Y outre ready for 


some info that will really make a cool isometric game. 


PART Ill 


ISOMETRIC 


METHODOLOGY 
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t's a brand-new day. Т he birds are chirping, the sun is shining, and all is right with the world. М ore 
importantly, you have survived the first two parts of this book, which means that you are ready to 
move on to some real stuff. Congratulations! 


T his chapter covers sort of a hodgepodge of isometric algorithms, and maily deals with layered maps. 
T here will also be some information on how to optimize the rendering of your iso map, and how to 
update discrete areas of the map. All in all, it should be a fun ride, and you should be saying, “Оһ, that's 
how you do that!” before youre done. 


As in previous chapters, the methods | will show you will be displayed in a manner that (1 hope) is the eas- 
iest to understand, which means that the methods arent necessarily the fastest or dont necessarily perform 
the best. H owever, once you have learned the basic idea of how to do something, | have full faith in your 
ability to find a way to do it faster and better. 


Also, you're going to be working with IsoH exCore, which was introduced in Chapter 15, "T he 
IsoH exCore Engine" I'll add components to it, and it will become a more robust engine as time goes on. 


W ithout further ado, let's get started, shall we? 


LAYERED WAP BASICS 


Just so that you and | are both on the same page (figuratively speaking), | want to explain exactly what | 
mean by a layered map. W hen | say layered map, | just mean that there is potentially more than one 

tile’ sprite blit on a given map location. Figure 16.1 shows a simple layered map. Sometimes, there is no 
need for а layered map. For example, you can make some board games without layering, although, you'd 
probably want to use then for most. For example, in a chess game, you might want to have separate images 
for the board tiles and the piece sprites, although nothing prevents you from making each piece on each 
board tile and just using a single layer. 


W hat is the main purpose of having layered maps? G епегаПу speaking, layered maps let you make richer 
worlds (and richer worlds are more immersive) while at the same time decreasing the number of actual 
tiles/ sprites needed. T his means you will need to use your artists less, and as а result, your art costs wont 
be as large. 


W ith a layered map, you can have only a limited number of tiles. For example, if you took three types of 
terrain (grassland, prairie, and ocean) a few tiles to build coastline (for iso, this can be done with as few as 
16 tiles) eight tiles for roads and a few tiles to represent forests, hills, towns, and so on from these 30 or 
50 tiles you could create a world that seams like it was made of hundreds of tiles. In reality, the map only 
consists of smaller tiles that are put together in different ways. 
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Figure 16.1 
A layered iso map 


In addition, layering tiles and sprites allows you to convey information about the tile to the user graphical- 
ly, letting him know where his units, characters, and buildings are, where his enemies are, what resources are 
available at a given location, and so on. 


LAYERED MAP METHODS 


N ow that you've seen the doors that layered maps open for you, you can start to really think about how 
you'll work with them. Basically, there are two methods: the tile scale method and the map scale method. 
In most instances either one will work, but there are subtle differences of which you should be aware. 


TILE SCALE LAYERING 


In tile scale layering, the layering occurs оп a per-tile basis. T his means that if you have а background of 
grassland and a tree on a tile, when the map drawing gets to that tile, it blits the grassland, then the tree, 
and then moves on to the next tile. 


Figure 16.2 shows a three-layer map using the tile scale method of layering, T he three layers are (from bot- 
tom to top) background (a simple green tile), shadow, and foreground. 
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Figure 16.2 


Tile scale layering 


TILE SCALE LAYERING EXAMPLE 


Load up 150Н ех16 1.срр. It requires all the standard stuff, including D D Funcsh/ D D Funcs.cpp, 

T ileSet.h/ T ileSet.cpp, and the 150Н exCore files. T his example is responsible for the image shown in 
Figure 16.2. M ostly, this sample program is the same as 150Н ех15 1.срр, with the map type code taken 
out and some extra tilesets loaded in. Т he main changes are in the blitting section of Prog Loop, but the 
differences arent limited to that section. 


T he first change is that instead of a single tileset for your images, you have a separate bitmap for each 
layer. T he background tile is stored in backgroundts.bmp. T he tree's shadow is in treeshadowts.bmp, 

and the tree itself is in treets.Jomp. Each of these tilesets has a single image, which might seem like a bit of 
a waste, but having them separate makes it easier to show how layering works. T he background is loaded 
by acTileset object called tsBack. T he shadow is loaded into tsShadow, and the tree is loaded into 
tsTree. T hisis all done within Prog Init, in the middle of the [50Н exCore initialization. 


T he next fundamental change is the manner in which the map is set up. Before, when you had several 
tiles and only one layer, you had it randomly choose an image to display. In this case, the background is 
the same for all tiles. T he only change from one tileto another is whether or not there is a tree. | picked 
the value 0 for "no tree" and the value 1 for "tree" H eres the code that sets up the map: 


//set up the map to a random tilefield 
for(int x=0;x<MAPWIDTH;x++) 
{ 
for(int y=0;y<MAPHEIGHT; у++) 
{ 
iMap[x][y]=rand()%2; 


LAYERED MAPS AND OPTIMIZED RENDERING 415 


15 really basic. Just assign a map square to rand 22, which gives you either а 0 or 1. N o major trickery 
occurring here! T he major change (blitting the map in Prog. Loop) isa little more involved. T he loop 
through the map positions is the same as normal; the changes occur in the inner loop. First, blit the back- 
ground tile, since the background is uniform for all areas. N ext, check to see whether the current map 
position coincides with the cursor. If it does, you blit the cursor onto that position. 


Finally, there is a check to see if а tre is at the current position. If there is a tree, blit the shadow and 
then blit the tree. If no tree exists, skip it. Easy enough, right?T ake а look at the code that does it: 


//plot our tiles 

POINT ptPlot; 

POINT ptMap; 

for(ptMap. y=0;ptMap.y<MAPHEIGHT;ptMap.y++) 
{ 


for(ptMap.x=0;ptMap.x<MAPWIDTH; ptMap. x++) 
{ 
//plot the tile 
ptPlot=TilePlotter.PlotTile(ptMap) ; 
//convert from world to screen 
ptPlot=Scroller.WorldToScreen(ptPlot) ; 
//put the background 
tsBack.PutTile(IlpddsBack,ptPlot.x,ptPlot.y,0); 
//check for cursor plotting 
if(ptMap.x--ptCursor.x && ptMap.y--ptCursor.y) 
{ 


tsCursor.PutTile(lpddsBack,ptPlot.x,ptPlot.y,0); 
} 
//check for tree 
if (iMap[ptMap.x][ptMap.y]==1) 
{ 


//put shadow 
tsShadow.PutTile(lpddsBack,ptPlot.x,ptPlot.y,0); 
//put tree 
tsTree.PutTile(lpddsBack,ptPlot.x,ptPlot.y,0); 
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N othing to it, right? If you had other foreground objects, like stones, signs, or buildings, you could handle 
it in pretty much the same way, except that the map position might have 0 to represent nothing, 1 to rep- 
resent a tree, 2 to represent another object, and so on. 


And now | have to apologize As it turns out, | lied about this example being a three-layer map. 
Technically, it is not. T he cursor can be considered a layer, squeezed between the background layer and the 
shadow layer. So if you want to be completely accurate about it, this is a four-layer, not a three-layer map. 
Luckily, I'm not too concerned about the cursor' layer, since | think of the cursor as an almost completely 
separate system. | just wanted to point out that it was technically a layer. ІЛІ say nothing more on the 
topic, and we wont consider the cursor layer from here on out. 


If you compile and run the example, you'll see something similar to Figure 16.2. By clicking, you can add 
and remove trees. М oving the mouse to the edge of the screen scrolls in that direction. T his is a rather 
simple example of a map editor, except, of course, that you cannot save or load your map. 


In this example, the fact that you are using tile scale layering introduces certain distortions to the images 
on the map. For example, if а tre is placed to the southwest of another tree, the southwest tree's shadow 
will cover the lower part of the other trees trunk. Figure 16.3 zooms in on this effect. [п many examples, 
this would be acceptable but not when you have a shadow layer. 


Figure 16.3 


Image distortions for tile 
scale layering 
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MAP SCALE LAYERING 


T he other method of layering is to apply layers one at a time to the entire map, rather than applying 
all the layers to a single tile. Figure 16.4 shows an example of this, using the same tree and tree shadow 
images you've been using. 


Figure 16.4 
Map scale layering 


MAP SCALE LAYERING EXAMPLE 


IsoH ех16 2.срр is the map scale layering example. T he code is almost identical to 150Н ех16_1.срр, with 
one small, but meaningful, exception. Т hat exception is the main rendering loop. О г, | should say, loops. 


In map scale layering, you apply one layer to the entire map and then move on to the next, which means 
that you have to do your nested тарх, mapy loops as many times as you have layers. You might be think- 
ing that this adds more overhead (because the plotted coordinates have to be calculated several times). 
True, the example does this, and so yes, you have more overhead than is necessary. H owever, this does not 
mean that the map scale type of layering is always less efficient than tile scale layering. Indeed it is not; 

it is simply less efficient in this case because of the way you set up the loop. 


H ereis the revised code for the rendering loops: 


//plot our tiles 

POINT ptPlot; 

POINT ptMap; 
for(ptMap.y=0;ptMap.y<MAPHEIGHT;ptMap. y++) 
{ 


for(ptMap.x=0;ptMap.x<MAPWIDTH; ptMap. x++) 
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//plot the tile 
ptPlot=TilePlotter.PlotTile(ptMap); 
//convert from world to screen 
ptPlot=Scroller.WorldToScreen(ptPlot); 
//put the background 
tsBack.PutTile(lpddsBack,ptPlot.x,ptPlot.y,0); 
//check for cursor plotting 
if(ptMap.x==ptCursor.x && ptMap.y==ptCursor.y) 
{ 


tsCursor.PutTile(IpddsBack,ptPlot.x,ptPlot.y,0); 


} 
for(ptMap.y=0;ptMap.y<MAPHEIGHT;ptMap.y++) 
{ 
for(ptMap.x=0;ptMap.x<MAPWIDTH; рЕМар.х++) 
{ 
//plot the tile 
ptPlot=TilePlotter.PlotTile(ptMap) ; 
//convert from world to screen 
ptPlot=Scroller.WorldToScreen(ptPlot); 
//check for tree 
if(iMapLptMap.x][ptMap.y]==1) 
{ 
//put shadow 
tsShadow.PutTile(lpddsBack,ptPlot.x,ptPlot.y,0); 


} 
for(ptMap.y=0;ptMap.y<MAPHEIGHT;ptMap.y++) 
{ 
for(ptMap.x=0;ptMap.x<MAPWIDTH; ptMap. x++) 
{ 
//plot the tile 
ptPlot=TilePlotter.PlotTile(ptMap); 
//convert from world to screen 
ptPlot=Scroller.WorldToScreen(ptPlot); 
//check for tree 
if (iMap[ptMap.x]iptMap.yJ==1) 
{ 
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//put tree 
tsTree.PutTile(lpddsBack,ptPlot.x,ptPlot.y,0); 


} 


As you can see, there are three sets of nested (x,y) loops, one for each layer. T he first set of for loops 
takes care of the background. T he next set takes care of the shadow layer, and the final set takes care of 

the foreground. T he cursor is plotted during the background layer (it just looks strange if done otherwise). 
If you compile and run the example, you'll get something that looks like Figure 16.4. 


In Figure 16.5, I've zoomed in on this example to show the subtle difference between tile scale and map 
scale layering. In the current example, all the shadows are drawn before any of the trees are, so none of the 
trees are obscured by the shadow like they are in the map scale example. M ostly, this is a matter of person- 
al preference. | prefer the look of the second, but you might prefer the look of the first. 


Figure 16.5 


Map scale layering 
close up 
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WHATS THE BiG DEAL? 


You might have been following along in this chapter wondering, “Well, who cares?” and thinking that I’m 
the most insane programming book author ever. You may be thinking it shouldn't matter what layering 
method you use, because it'll turn out OK either way, right? | will conditionally agree with you. If none of 
your art extends beyond the background tile shape, like it does in most hexagonal strategy games, it doesnt 
matter, since with either method you will have the same net result. 


H owever, with isometric maps, it is quite rare to have graphics that do not extend outside the basic tile 
shape, which means that the order of layer rendering does have an impact on the map’s final appearance. 


A MORE EFFICIENT TILE BLITTING 
ALGORITHM 


U p until this point, every single isometric application weve written has drawn the entire map every frame. 
After chapters and chapters of doing this, I’m telling you not to do it anymore. It's fine if you have a small 
number of tiles, not more than a few hundred. But if you have several thousand tiles, and several layers, 
you will start to see some performance hits if you blit every tile every time. 


An old game programming rule is never to draw anything you dont have to. T his is harder to do than it 
sounds, especially in isometric graphics. So, the problem is how to fill in the screen (or, really, any rectan- 
gular area) with isometric tiles and sprites without drawing more tiles than you have to? 


T he answer lies in the M ouseM ар. Т he М ouseM ap, you remember, converts screen coordinates into map 
coordinates. H ence, you can determine what map locations are at the corners of the screen, and, based 

on those map locations, you can blit only map locations that should appear on the screen. (To be honest, 
you'll include an extra row or two of tiles because of layering. T hat's an extra 20 or so tiles— a small price 
to pay in order to not blit 10,000 tiles.) 


T he main problem with using the M ouseM ap is that you cannot use it in its current configuration. 

W hatever corner map locations you pick, they have to be in the same row and column as the other corner. 
As Figure 16.6 shows, that cannot be done with the current M ouseM ap. In this figure, the lightly shaded 
section shows the screen rectangle, and the darkly shaded tiles indicate the tiles found at the corners of 
the screen space. Plainly, deciding what tiles to blit based on these results is a matter of guesswork, and 

it would be impossible to come up with a solution that would work in all cases. So, you have to abandon 
using the M ouseM ap as-is for an isometric map. 


LAYERED MAPS AND OPTIMIZED RENDERING +21 


Figure 16.6 


Using the M ouseM ap as-is 


t 


H owever, there is one type of map that can use the M ouseM ap as is to accomplish this task— the rectan- 
gular map. Figure 16.7 shows a rectangular map, with the corner map locations of screen space shown 
darkly shaded, and the tiles that need to be shown lightly shaded. From this figure, you can see how easy it 
is to update a rectangular map without writing more tiles than you have to. You simply loop from left to 
right and top to bottom, blit them, and go. 


LI. T I | emis 
Using the M ouseM ap on a 
rectangular map 
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You are dealing with isometric tiles, not rectangular tiles, so this stuff about rectangular tiles 

cant help you, right? W rong, of course, or | wouldnt have mentioned it. T hink for a moment about how 
the M ouseM ap works. First, it takes a screen coordinate and translates it to a world coordinate using a 
scroller. N ext, it changes world coordinates into M ouseM ap coordinates, both coarse and fine. N ow, stop 
here for a moment. 


T he phrase calailate coarse M ouseM ap coordinates means nothing more than divide the area into smaller retanges. 
You need rectangles if you want to limit the number of blits per loop. 


Take a look at Figure 16.8, which shows a possible screen space (the inverted rectangular section) amid 
a number of M ouseM ap images (which will serve as the rectangular area). It is now quite obvious what 
tiles you need to blit, but you need a solution that will work no matter where the screen space rectangle 
is located. 


Figure 16.8 


M ouseM ap coordinates 


T he M ouseM ap coarse coordinate takes you only halfway to where you want to go, but at least it's a start. 
You know that if a given rectangular area intersects with the screen space rectangle, at least one of the iso 
parts that comprise it must be drawn. But, you arent concerned with the "at least" Instead, you are con- 
cerned with “at most.” At most, having a given M ouseM ap rectangle intersecting with your screen space 
means that you have to redraw five tiles: the central tile and each of the corner tiles. N ow you're really get- 
ting somewhere, 


If you figure out the M ouseM ap coarse coordinates of each corner, figure out the map location of the 
center tile and then move one step in the same direction as the corner (for example, in the northwest cor- 
ner, move one step northwest), you will have specified a range of tiles that you can draw. Each corner will 
align with the other corners, and you'll be able to loop through the tiles without a problem. (Wal, with 
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only minor problems. You'll have to use пет ileW alker quite a bit to make this work right, but I'll get 
back to that in a minute) 


Figure 16.9 shows a possible screen space, the corner M ouseM aps, and the corner isometric tiles. 

H opefully, this is a better representation of how this concept works. | know that the wording is alittle 
difficult to understand if you're just reading it. It sounds like a recipe for chocolate chip cookies written 
in Arabic. 


Figure 16.9 


Isometric corners 
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As you can see, the four iso tiles are nicely aligned so that to walk from the northwest corner to the north- 
east corner, you can simply take eastward steps, as shown in Figure 16.10. So, from a calculated starting 
location, you simply walk until you hit the other corner. 


ISOMETRIC GAME PROGRAMMING wItTH, DIRECTX 7,0 


Figure 16.10 
Walking left to right 
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Similarly, you could walk top to bottom, except you would skip alternate rows of tiles that need blitting, 
so you'll take а zigzag path down each side. On the left side, you will alternately move southeast and 
southwest. On the right side, you will alternately move southwest and southeast (that is, opposite of the 
direction you are moving the left edge). 


T his brings me to an important point. You have to keep track of both edges at all times, because not only 
do you tilewalk from the left to the right, but afterward you also walk diagonally from that point. In other 
words, this will involve а whole lot of somewhat messy and hard-to-read code. 


I'll show you a programming example soon, but first | want to lay out the algorithm, just in case my expla- 
nation up until now has left you wondering. 


1. Calculate the coarse М ouseM ap coordinates for each corner of the screen space. 

2. Determine the map location of the central tile of the M ouseM ap corresponding to the coarse 
M ouseM ap coordinate calculated in Step 1 (that is, the map location where the lookup has an 
MM CENTER). 

3. For each of the map locations from Step 2, take one step away from the screen space T his 
means that the northwest corner takes a step to the northwest, the northeast corner takes a step 
to the northeast, and so on for southwest and southeast. 

4. Set afew control variables: RowCount counts the number of rows blitted, starting with 0. 
RowStart and RowEnd mark the beginning and end of rows. It starts with the value of the map 
locations for northwest and northeast, respectively. 

5. Start at RowStart and blit tiles and move east until RowEnd has been blitted. 

6. If RowCount is even, move RowStart to the southeast and RowEnd to the southwest. 
Otherwise move RowStart to the southwest and RowEnd to the southeast. 

7. Increase RowCount by 1. 
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8. If RowStart is at or above the southwest corner, return to Step 4 to blit another row. 
9. All the required tile rows have been blitted, but you might want to blit an extra row or two 
for taller structures that might be on their tiles. 


You'll notice something about this method. It doesnt have the words "For Slide М aps,’ “For Staggered 

M aps,” or "For Diamond M aps,” and wall it should not. T his algorithm is independent of map type, and 
it will work for any of them. Т he only issue you should be wary of is nonexistent tiles. T he map location 
found by the M ouseM ap might not be within the map's range, so you need a “reality check" before going 
ahead and blitting the tile in question. 


CODE EXAMPLE: REDUCING THE Numen 
OF BLITS PER FRAME 


Finally, it’s time for a programming example. Load up IsoH ex16 3.cpp. If you are still a little confused 
by the explanations so far, this example is a concrete application of what I've been discussing. T he first 
thing I'd like to point out about IsoH ех16 3.cpp is that it is rather similar to SoH ех16 1.cpp. It uses 
tile scale layering, for one, since that makes it easier to show the rendering loop. T he second thing | want 
to point out is that | have increased the map’s size from the 20x40 you saw earlier in the chapter to 
200x400, a hundred-fold increase in size. 


T his brings up the question “W hy the size increase?" W ell, if you were to take one of the other examples 
from this chapter and increase the map similarly, you would see a drastic reduction in performance. In 
other words, it would be incredibly slow. D ont take my word for it, though. Go ahead and load up one 
of the other examples, change the map size to 200x400, and run it. N o, really— go ahead. | can wait. 


Back? Good. N otice how slow that was? W hen | did it, it seemed to take ages to scroll even a slight 
amount. T hat's because the program is blitting every map location every frame. W ith 20x40, at an average 
of two blits per map location, that is 1,600 blits per frame, which most computers today can handle with- 
out too much of a problem. H owever, increasing that to 160,000 blits per frame causes such a perform- 
ance hit that you might be tempted to go back to your day job. 


W ith the algorithm I've been talking about, you can reduce the number of blits per frame so that only 
those tiles that need to be blitted to the screen will be blitted. (Actually, for good measure, you throw in 
a few extras around the edges, but a few extra blits isnt 160,000.) 


First, l'm going to show some rough figures. You are currently using a 640x480 display mode and tiles 
that are 64x32. If your tiles took up the entire 64x32, you would need to blit only 15 rows of 10 
columns each. Y our tiles overlap, and each row is offset by only half a tiles height, so you really need about 
10x30 map locations blitted per frame. For the bordering tiles, you have to expand this by one tile in each 
direction, so you end up with 12x32 map locations that probably should be blitted per frame. W ith an 
average of two blits per map location, this makes for 12x32x2 or 768 blits per frame, which is less than 1 
percent of the 160,000 for a 200x400 map, and half of thefigurefor a 20x40 map. 


ISOMETRIC GAME PROGRAMMING wItTH, DIRECTX 7,0 


In conclusion, this is something you déinitdy want to do. So 165 do it. М ost of IsoH ex16 3.cpp is the 
same as the other examples, as far as how it is initialized, how it is cleaned up, and how it responds to 
various events. T he only real difference is the rendering loop, which takes place during Prog. Loop. 


T he rendering loop has two parts. First is the preparatory stage, in which you use the M ouseM ap to figure 
out what map locations bound the area you want to blit. Second is the rendering loop itself, which loops 
between these calculated locations and draws the images. | should warn you that some of this codeis a 
little on the "evil" side, meaning that it might at first look a little strange and doesnt necessarily follow 
good programming practice. D ont let that deter you. At least it's fast! 


PREPARATORY STAGE 


T he preparatory stage calculates the corners from which you will be looping in the rendering loop. Each 
corner is calculated separately and uses calculations in the same way, just with different starting positions. 
I'll show only the upper-left corner calculation and then tell you what is different for the other corners. 


//screen point 
ptScreen.x=Scroller.GetScreenSpace()->left; 
ptScreen.y=Scroller.GetScreenSpace()->top; 


H eve, you start with the screen coordinate that corresponds to the upper-left corner of the screen space. 
In this case it is (0,0). | could have just used 05, but | wanted to show that this method can be used for 
any rectangular area. H int: this is important information for later in this chapter. 


//change into world coordinate 
ptWorld=Scroller.ScreenToWorld(ptScreen) ; 
//adjust by mousemap reference point 
ptWorld.x-=MouseMap.GetReferencePoint()->x; 
ptWorld.y-=MouseMap.GetReferencePoint()->y; 


N ext, | translated these coordinates into world space and adjusted then by the M ouseM ар5 reference 
point. As you can see, | am using a method very similar to the method of mousemapping that | intro- 
duced in Part І. 


//calculate coarse coordinates 
ptCoarse.x=ptWorld.x/MouseMap.GetWidth(); 
ptCoarse.y=ptWorld.y/MouseMap.GetHeight(); 


№ ext, on to more mousemapping stuff. T hese are the calculations of the coarse M ouseM ap coordinates, 
which you need to find the M ouseM ар5 central tile. 


//adjust for negative remainders 
if(ptWorld.xZMouseMap.GetWidth()«0) ptCoarse.x-; 
if(ptWorld.y%MouseMap.GetHeight()<0) ptCoarse.y-; 
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You've seen this before. You have to adjust for negative world coordinates. 


//set map point to 0,0 

ptMap.x=0; 

tMap.y=0; 

/do eastward tilewalk 
tMap-TileWalker.TileWalk(ptMap,ISO EAST); 
tMap.x*=ptCoarse.x; 

p.y*=ptCoarse.x; 

/assign ptmap to corner point 
tCornerUpperLeft.x=ptMap.x; 
tCornerUpperLeft.y=ptMap.y; 
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О kay, this is where | start to deviate from normal mousemapping algorithms. You start with а map point 
of (0,0) and retrieve from theT ileW alker by how much a step to the east will change it. T hen you multi- 
ply by the coarse coordinates x location. T his serves the same purpose as doing a loop with single tilewalks 
to the east. An eastward walk is always consistent, no matter what type of iso map you are using, so 

this manner of doing a multi-tilewalk is acceptable. H owever, | still dont suggest using this method for 
diagonal directions. T he results of the multiplication are assigned to the corner point variable. 


//reset ptmap to 0,0 

ptMap.x=0; 

ptMap. y=0; 

//do southward tilewalk 
ptMap-TileWalker.TileWalk(ptMap,ISO SOUTH); 
ptMap.x*=ptCoarse.y; 

ptMap.y*=ptCoarse.y; 

//add ptmap to corner point 
ptCornerUpperLeft.x+=ptMap.x; 
ptCornerUpperLeft.y+=ptMap.y; 


H ere, you use a similar idea with the southward tilewalk, after first clearing out the map location. T his 
time you add the value to the corner point variable. South is another direction in which the walker is 
always consistent. 


So, you now have the central tile of the M ouseM ap that corresponds to the upper-left corner of the 
screen space. Т he rest of the corners are calculated in a similar way, just starting with a different screen 
coordinate at the top. After you've calculated all the corners, walk one step away from the screen space, as 
shown in the following code snippet: 


//tilewalk from corners 
ptCornerUpperLeft=TileWalker.TileWalk(ptCornerUpperLeft, ISO_NORTHWEST) ; 
ptCornerUpperRight=TileWalker.TileWalk(ptCornerUpperRight, ISO_NORTHEAST) ; 
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ptCornerLowerLeft=TileWalker.TileWalk(ptCornerLowerLeft, ISO_SOUTHWEST) ; 
ptCornerLowerRight-TileWalker.TileWalk(ptCornerLowerRight,ISO SOUTHEAST) ; 


N ow you have map locations guaranteed to be at least partially outside the screen space, and your calcula- 
tions are complete. Youre ready to render! 


RENDERING Loor 


T he preparatory-stage code wasnt too terrible, right? It’s pretty straightforward, | think. It just has а lot 

of lines. T his next bit might not seem nearly as straightforward. Since you have no way of knowing where 
the corners are, and no way of knowing what map type is being used for the map, this means that you also 
dont know how many steps to the east the upper-right corner is from the upper-left corner. N or do you 
know how many steps south the lower-left corner is from the lower-right corner. N ot knowing these things 
is both good and bad. Т he good part is that you dont actually have to know in order to render correctly. 

T hat means that this method will work with any map type and any screen size, or even any portion of 

the screen you want. Т he bad part is that it makes the code kind of strange to look at. Check it out: 


//set up rows 
ptRowStart=ptCornerUpperLeft; 
ptRowEnd=ptCornerUpperRight; 
//start rendering loops 
for(;;)//"infinite" loop 
{ 
//set current point to rowstart 
ptCurrent=ptRowStart; 
//render a row of tiles 
for(;;)//’ infinite’ Тоор 
{ 

//check for valid point. if valid, render 
if(ptCurrent.x>=0 && ptCurrent.y>=0 && 
ptCurrent.x<MAPWIDTH && ptCurrent.y<MAPHEIGHT ) 
{ 

//valid, so render 
ptScreen=TilePlotter.PlotTile(ptCurrent);//plot tile 
ptScreen=Scroller.WorldToScreen(ptScreen) ;//world->screen 
tsBack.PutTile(lpddsBack,ptScreen.x, 

ptScreen.y,0);//put background tile 
if(iMapL[ptCurrent.x][ptCurrent.y])//check for tree 


tsShadow.PutTile(lpddsBack,ptScreen.x, 
ptScreen.y,0);//put shadow 
tsTree.PutTile(lpddsBack,ptScreen.x,ptScreen.y,0);//put 
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tree 
} 
} 
//check if at end of row. if we are, break out of inner loop 
if(ptCurrent.x==ptRowEnd.x && ptCurrent.y==ptRowEnd.y) break; 
//walk east to next tile 
ptCurrent-TileWalker.TileWalk(ptCurrent,ISO EAST); 
} 
//check to see if we are at the last row. if we are, break out of loop 
if(ptRowStart.x==ptCornerLowerLeft.x && ptRowStart.y==ptCornerLowerLeft.y) 
break; 
//move the row start and end points, based on the row number 
if (dwRowCount&l ) 
{ 
//odd 


//start moves SW, end moves SE 
ptRowStart=TileWalker.TileWalk(ptRowStart, ISO_SOUTHWEST) ; 
ptRowEnd-TileWalker.TileWalk(ptRowEnd,ISO SOUTHEAST) ; 


else 


//even 
//start moves SE, end moves SW 
ptRowStart-TileWalker.TileWalk(ptRowStart,ISO SOUTHEAST); 
ptRowEnd-TileWalker.TileWalk(ptRowEnd,ISO SOUTHWEST) ; 

} 

//increase the row number 

dwRowCount++; 


W hat might throw you is that there are two nested infinite for loops (the for’; ; ), which does the same 
thing as a while(true)). N ow that you Ve seen it all at once, you're probably saying, “H uh?” and perhaps 
checking how strong your keyboard is by hitting your head on it a few times. It's weird code, and | didnt 
have fun debugging it, | can tell you. Trust me, there were plenty of bugs. 


I’m going to change the way these loops look so that | can explain them a little better. First, l'II tackle the 
outer loop: 


//set up rows 
ptRowStart=ptCornerUpperLeft; 
ptRowEnd=ptCornerUpperRight; 
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T his sets up the two ends of the tile rows. You start at the top and move down. T he ptRowStart variable 
contains the west end of the row, and the ptRowEnd variable contains the east end of the row. 


//start rendering loops 
for(;;)//"infinite" Тоор 
{ 


Oh joy!Youve started your outer "infinite" loop. Since the loop has no exit condition, at some point you 
need to have а method of determining that you are done and use break to get out of it. 


//set current point to rowstart 
ptCurrent=ptRowStart; 


T he ptcurrent variable keeps track of the map location that you are currently rendering. W ith each new 
row, you set it to ptRowStart and then move eastward from there. 


//render a row of tiles 
RenderRow();//this replaces the inner loop 


RenderRow Isnt a real function. It just replaces the inner loop, which renders each tile and then moves east- 
ward until ptRowEnd is reached. 

//check to see if we are at the last row. if we are, break out of loop 

if (ptRowStart.x==ptCornerLowerLeft.x && ptRowStart.y==ptCornerLowerLeft.y) 
break; 


T his is the exit condition. If the current value of ptRowStart is the same as the lower-left corner of the 
tile range, you are done T his check is done after the row is rendered to ensure that you get all the rows 
blitted. 


//move the row start and end points, based on the row number 
UpdateRowEnds();//this code replaces the row start and row end movement 
code 


T here is also no UpdateRowEnds function. T his just replaces the code used to modify the гом start and 
end variables. l'Il explain it in better detail later; it's different depending on whether the awRowCount vari- 
able is odd or even. 


//increase the row number 
dwRowCount++; 


Finally, you increase dwRowCount, which affects the behavior of UpdateRowEnds. dwRowCount Starts at 0. 
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So, now the outer loop is demystified. О n to the inner loop (the code replaced by RenderRow() in the 
inner loop): 


//render a row of tiles 
for(;;)//’ infinite’ loop 
{ 


Ah, the inner "infinite" loop. You already have ptCurrent initialized to ptRowStart, so you can work 
with it from there. 


//check for valid point. if valid, render 
if(ptCurrent.x>=0 && ptCurrent.y>=0 && 
ptCurrent.x<MAPWIDTH && ptCurrent.y<MAPHEIGHT ) 
{ 
//valid, so render 
RenderTile();//replaces actual tile rendering code 


T he first check you have to do is to make sure that ptCurrent is an actual tile іп the map, which means 
it has to be at least 0 and less than the height. If the point falls within the proper range, you can go ahead 
and render it. T he RenderTile function is a replacement for the actual tile-rendering code. 


//check if at end of row. if we are, break out of inner loop 
if(ptCurrent.x--ptRowEnd.x && ptCurrent.y--ptRowEnd.y) break; 


Just as you needed an exit condition to get out of the outer loop, you also need one here in the inner loop. 
In this case, check to see if ptCurrent equals ptRowEnd. If it does, break out of the loop. 


//walk east to next tile 
ptCurrent-TileWalker.TileWalk(ptCurrent,ISO EAST); 


Last, walk to the next tile, taking a step to the east, and continue the row. T his algorithm isnt nearly 
as bad as it appears, once you start to take it apart and make pseudocode out of it. 


T he last bit | have to cover is the part of the outer loop that was replaced by UpdateRowEnds(). 
T hankfully, it doesnt include another infinite for loop! 


if (dwRowCount&l ) 
{ 


//odd 

//start moves SW, end moves SE 
ptRowStart=TileWalker.TileWalk(ptRowStart, ISO_SOUTHWEST) ; 
ptRowEnd-TileWalker.TileWalk(ptRowEnd,ISO SOUTHEAST) ; 
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else 


//even 

//start moves SE, end moves SW 
ptRowStart=TileWalker.TileWalk(ptRowStart, ISO_SOUTHEAST) ; 
ptRowEnd=TileWalker.TileWalk(ptRowEnd, ISO_SOUTHWEST) ; 


T his is probably the most straightforward part of the rendering loop. T his bit of code is called after a row 
has been rendered. If you are on an odd row (dwRowCount&11-0), you have to move the ends of the row 
outward (ptRowStart to the southwest and ptRowEnd to the southeast). If you are on an even row, you 
move inward instead. T his gives you a zigzag in the southerly direction, which is what you want. 


N ow you've got an algorithm that limits the blitting in your rendering loop to a manageable number of 
tiles. H owever, it should not satisfy you. Sure, it blits only those tiles that really need it, but ask yourself 
this question: Frame by frame, how many map locations really change and really need to be redrawn?T he 
answer is just one, unless you're scrolling. W hen scrolling, you need to update more of the map since 
everything moves, but there are also ways of limiting that. 


[п addition, are the calculations in the “preparatory stage" really necessary for all four corners? Couldnt 
you just calculate an offset for the other four corners based on the upper-left?T he fact of the matter is 
that there are many things you can do to optimize this method and optimize your isometric engine in gen- 
eral. And yes, you will do all of these things before you are done. 


T heres something | want to point out about IsoH ex16_3.cpp before we move оп. № ext time you run the 
program, start scrolling to the right slowly, at maybe one or two pixels per frame. W hile you are scrolling, 
keep watching the left side of the screen. You will see that as you scroll, certain tree shadows vanish before 
they are fully off the screen. If you then scroll back to the left, you will see these same shadows suddenly 
appear (you can see the same thing happen if you scroll up or down and watch the bottom of the screen). 
T his is yet another rendering problem with isometric graphics. Since some of the images extend beyond 
the tile, you sometimes have to blit for areas that arent actually on-screen in order to avoid the sudden 
appearance and disappearance of images. After all, you want the user to think that the screen is just a little 
camera into this isometric world and have a consistent picture no matter where that camera is located. 


So, how can you avoid this problen?W ell, to fix the left-right scrolling problem, you could move the 
upper-left and lower-left corners опе tile to the west. Yes, you will have to blit a few more tiles this way, 
maybe an extra 30 or so, but the cost will be well worth it. Similarly, to solve the up-down scrolling prob- 
lem, you could move the lower-left and lower-right corners south by one tile Again, blit a few more tiles 
for added realism. 
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If you have exceptionally tall or wide images, you might want to extend the corners farther. T his calls for 

some judgment on your part. Do you use an exceptionally tall image? О г do you split it into two smaller 

images and place each image to get the illusion of a very tall structure instead?T he choice is yours. Either 
way has its pluses and minuses. 


SUMMARY 


In this chapter, you broke out of your shell, so to speak. You took the basics from Part | and started to 

mold then into something real. Y our journey is far from over, but hopefully you are starting to see what 
you can do with this isometric stuff. You've explored layering and optimizing the rendering loop, both of 
which are fundamental if you ever plan on writing an isometric engine or game that really performs well. 
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FURTHER RENDERING OPTIMIZATIONS 


n the last chapter, | introduced you to the idea that you can render faster by not rendering everything 
1 all the time. In this chapter, 171 take this concept even further— in fact, to the very limits of what you 
can do (at least, within the bounds of using DirectX ). You'll add anew component, the map гепдегег, to 
your list of isometric components. In any case, it should be an interesting experience, so let's get going! 


GET п оғ BLT 


You've been using the стітеѕе+ class for a while now, and you've gotten some very good mileage out of it. 
It serves well as a tile/ sprite blitter. H owever, it relies оп IDirectDrawSurface7::81t to do the rendering 
and uses IDirectDrawClipper to do the dipping. 


T his, my friend, is just not acceptable. You have all the information you need to do your own dipping— 
namely, rcScreenSpace in the CScro11er Class. You also have the extent rectangles of all your tiles stored 
in your CTileSet. Surely, by using some simpleW IN 32 вест functions, you can eliminate the need for a 
clipper, and also for 81t, and replace both of these with the faster B1tFast. 


Take a gander at Figure 17.1. On the left, a source image is being blitted onto a larger image on the right. 
T he dark boxes represent the bounding rectangles. W hen you blit a partially visible image onto a surface, 

the clipper is what decides which portion of the image is actually blitted, and which portion is not, based 
on the dipping area with which you've made your clipper. 


Figure 17.1 

The current state of 
affairs: using B1t with 
a Clipper 


<> Portion Blitted Destination Image 


Portion Not Blitted 
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Consider this: [Di rectDrawC1ipper 15 a general-purpose object, and early on | told you that general-pur- 
pose objects are not necessarily good for performance. T he example | used at the time was СОТ, but the 
same idea applies here. You have no idea how a dipper works internally; it might be the worst-performing 
code ever written. | doubt that, but it's possible. 


Also, you dont really need a clipper. Your clipping area is a single rectangle If it were a number of rectan- 
gles, you might be justified in using a clipper, but you should be able to work with a single rectangle by 
yourself. And that is precisely what you will do. 


First, take a look at how you will do this. W hen using вт, you have to specify a source rectangle and а 
destination rectangle. W ith B1tFast, you only have to specify a destination point and a source rectangle. 
Take a brief look at B1tFast as a refresher: 


HRESULT IDirectDrawSurface7::BltFast( 
DWORD dwX, 
DWORD dwY, 
LPDIRECTDRAWSURFACE7 lpDDSrcSurface, 
LPRECT lpSrcRect, 
DWORD dwTrans 

); 


As with all DirectX member functions, B1trast returns an HRESULT, which contains either po. ok, mean- 
ing that no error occurred, or a DDERR_* constant, meaning that a problem was encountered. Table 17.1 
explains the parameter list. 


Table 17.1 BltFast Parameter List 


Parameter Purpose 
dwX The destination coordinate for the left of the image 
dwY The destination coordinate for the top of the image 


lpDDSrcSurface The source surface 
lpSrcRect The source rectangle 
dwTrans Flags specifying how the blit is to occur 


T he awrrans parameter is one or more of the flags listed in Table 17.2. 
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Table 17.2 Flags for dwTrans 
Flag Purpose 


DDBLTFAST_DESTCOLORKEY The blit is to use the destination color key 
DDBLTFAST_NOCOLORKEY The blit is not to use any sort of color key 
DDBLTFAST_SRCCOLORKEY The blit is to use the source color key 

DDBLTFAST. WAIT Instructs DirectDraw to wait until the blit is completed 


M ainly, you are interested in using DDBLTFAST_SRCCOLORKEY and DDBLTFAST. WAIT, Since you have trans- 
parent areas in almost all your isometric images. 


MOVING TO fSiLTTms5sT 


N ow your task is to figure out what to put into these parameters. Y ou already know how to find a destina- 
tion rectangle for the entire image. Simply take the extent rectangle and add the destination point to it. 


//dstX,dstY are a destination point 

//rcExt is the extent rect for the entire image 

//rcSre is the sourc rect for the entire image 

//rcDst is the destination rect for the entire image 
CopyRect(&rcDst,&rcExt);//copy the extent rect into the destination rect 
OffsetRect(&rcDst,dstX,dstY);//offset the destination rect by the destination 
point 


Га like to point out something here that will help you a little later. All three вЕСТ$ (rcSrc, rcDst, and 

rcExt) have the same height and width (right-left and bottom-top come up with the same number for 

each RECT). Н ence there is a number by which you can offset each of these кестѕ to change it into the 
exact same value as another nec. T his little tidbit will help you. 


//changeX, changeY is the difference between the left and top of rcDst and 
FESTE: 

//adding changeX and changeY to any destination pixel will convert it 

//to a source pixel 

changeX=rcSrc.left-rcDst.left; 

changeY=rcSrc.top-rcDst.top; 
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Skeptical? | know | would be Very well— I'll prove that this will work. Т he following looks somewhat like 
code, but it is not. 
//left 


rcDst.leftt+changex= 
rcDst.left+rcSrc.left-rcDst.left= 
rceSrc. left 


//right 
rcDest.right+changex= 
rcDst.righttrcSrc.left-rcDst.left= 
reSrc.leftt(rcDst.right-rcDst.left)= 
rcSrc.left-WIDTH- 

rcSrc.right 


Do need to go on and do top and bottom too? Or do you trust me now? 


Your next task is to clip the destination rectangle. To do this, you need a rectangle to clip, which | will 
conveniently supply in the form of rcc1ip. W hen you do this for real, this will be rcScreenSpace from 
а CScroller object. 


//determine the clipped destination coordinate 
//rcDstClipped will contain the clipped destination 
IntersectRect(&rcDstClipped,&rcDst,&rcClip); 


N ow you have your clipped destination вест; you are most of the way there. You just have to figure out 
the dipped source RecT and perform the 81tFast, and youre done. Of course, you first have to check 
to make sure that rcDstC1ipped is not an empty rectangle If it is, there is no reason to proceed. 


//check to see if clipped destination is empty 
if(!IsRectEmpty(&rcDstClipped) ) 
{ 
//non-empty rectangle, so calculate clipped source rect 
CopyRect(&rcSrcClipped,&rcDstClipped);//copy clipped destination 
//to clipped source 
OffsetRect(&rcSrcClipped,changeX,changeY);//change to source coords 
//perform the bltfast 
lpddsDst- 
»BltFast(rcDstClipped.left,rcDstClipped.top,lpddsSrc,&rcSrcClipped, 
DDBLTFAST SRCCOLORKEY | DDBLTFAST WAIT); 
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T hat's it! You're done! At first glance, this might look like a lot of code, but it really isnt. М ainly, all youre 
doing is adding integers together and assigning integers, which on any machine is pretty quick, and takes a 
negligible amount of time T he bottleneck in any graphically intensive application (like all the isometric 
sample programs) is the rendering, not the calculations. 


+ BLTFAST EXAMPLE 


W hat's next?W dl, it's time to put this algorithm into practice by extending the cTileSet dass. Load 
up ISoH ех17 1.срр, where! have done just that. T his example is based on 150Н ex16 3.cpp. 


| didnt want to completely redesign the стітеѕе+ dass; | just wanted to extend it. | chose to do so by 
adding a member function called cl iptile.T he declaration is shown here: 


void CTileSet::ClipTile( 
LPDIRECTDRAWSURFACE7 lpddsDst, 
RECT* prcClip, 
int xDst, 
int yDst, 
int iTileNum 

23 


T his member function returns no values. Table 17.3 explains the parameters. 


Table 17.3 ClipTile Parameters 


Parameter Purpose 


IpddsDst The destination surface to which the BitFast will occur 

prcClip A pointer to a ВЕСТ that will be used for clipping 

xDst The destination x-coordinate for the tile (used to calculate the 
destination RECT) 

yDst The destination y-coordinate for the tile (used to calculate the 


destination RECT) 
iTileNum The tile number to be blitted 
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In anutshell, clipTite is just like PutTile, but with an added parameter, prcc1ip, which is what the 
function uses to perform its clipping. N ow, takea look at the function itself. 


void CTileSet::ClipTile(LPDIRECTDRAWSURFACE7 lpddsDst,RECT* prcClip, 
int xDst,int yDst,int iTileNum) 


{ 
//source and dest rects 
RECT rcSrc; 
RECT rcDst; 
//changex and changey 
int changex; 
int changeY; 
//get the destination rectangle 
CopyRect(&rcDst, &GetTileList()LiTileNum].rcDstExt); 
OffsetRect(&rcDst,xDst,yDst); 
//calculate changex and changey 
changexX=GetTileList()LiTileNum].rcSrc.left-rcDst. left; 
changeY=GetTileList()LiTileNum].rcSrc.top-rcDst.top; 
//clip the destination rect to the clipping rect 
IntersectRect(&rcDst,&rcDst,prcClip); 
//check to see if the destination rectangle is not empty 
if(!IsRectEmpty(&rcDst)) 
{ 


//copy dest rect to source 

CopyRect(&rcSrc,&rcDst); 

//offset the source rect by changex/y 

OffsetRect(&rcSrc,changeX,changeY); 

//do the bltfast 

lpddsDst-»BltFast(rcDst.left, rcDst.top, GetDDS(), &rcSrc, 
DDBLTFAST SRCCOLORKEY | DDBLTFAST WAIT); 


T his function uses the exact same algorithm outlined earlier, just with fewer actual REcTS. | use only two 
because... well, that's the fewest | could get away with. Allocating local variables takes time, so | wanted to 
allocate as few as possible. Admittedly, the allocation doesnt take very much time, but why hurt yourself 
when you dont have to, right? 


T here are а few other minor changes іп 150Н ех17 L.cpp. First, the clipper is gone In order to use 
BltFast, you cannot use a clipper. T hat is just the way of things. Your goal was to get rid of the clipper 
anyway, right? Another change has to do with the rendering loop, and is in the form of replacing the calls 
to PutTile with calls to c1:pri1e. An example is shown here: 
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tsBack.ClipTile(IpddsBack,Scroller.GetScreenSpace(),ptScreen.x,ptScreen.y,0); 
//put background tile 


T his line in particular replaces the call to Put Tile that you previously used to draw the background tile. 
N o big deal; I'm just moving to the new (better) form of tile blitting. 
You'll probably see a few other minor changes as well. W hen scrolling, you no longer have the magically 


appearing and disappearing images on the left and bottom of the screen. T he code responsible for that 
mirade is as follows: 


//move left corners to the west by one 
ptCornerUpperLeft-TileWalker.TileWalk(ptCornerUpperLeft,ISO WEST); 
ptCornerLowerLeft-TileWalker.TileWalk(ptCornerLowerLeft,ISO WEST); 
//move the lower corners to the south by one 
ptCornerLowerLeft-TileWalker.TileWalk(ptCornerLowerLeft,ISO SOUTH); 
ptCornerLowerRight-TileWalker.TileWalk(ptCornerLowerRight,ISO SOUTH); 


Actually, | mentioned this concept in the last chapter; we just didnt get around to actually doing it. Simply 
move the left side one tile to the west and the bottom one tile to the south to give yourself a consistent 
picture no matter how you scroll. 


Last, there is a very, very minor change that ironically is the most noticeable of all.| changed the screen 
space. Instead of being the entire screen, it is now only 480x480. T here was a purpose to this change, of 
course. | wanted to show just how good our little c1:pri1e function is. N ot a single pixel is plotted out- 
side the screen space, which is the RECT you supply to your c1ipri1e function. T his will have important 
ramifications later. 


Мініпттілме DOUN THE BLITS 
PER FRAME 


So you've successfully passed your first hurdle— eliminating the less-than-optimal 81+ and replacing it with 
the more optimal 81 tFast.T his is a huge win for our team! (Yay team!) You still have а bit of work 
ahead, though. N ext, 171 show you how to even further reduce your blitting overhead by using off-screen 
frame buffers. You might be thinking, "But | already have a back buffer.” Yes, you do. Т he back buffer has 
served you well by allowing you to go smoothly from one frame to another without flicker. As you 
progress, the back buffer will continue to serve you in this capacity. 


Н owever, there is a problem with the back buffer. It has to be completely redrawn for every frame. W all, 
for any frame in which scrolling has occurred, which, in the examples so far, might as well be every frame. 
T he problem stems from the fact that after the main surface is flipped, the contents of the back buffer are 
from two frames ago. If you have been scrolling for the last two frames, the back buffer might as well be 
full of random pixels, because it will do you no good. If there has been no scrolling during the past two 
frames, the contents of the back buffer should ре the same— unless you just clicked to add or remove а 
tree, in which case it isnt quite the same. 
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See what | mean? Keeping track of the contents of two frames ago is a logistical nightmare, which is why 
up until this point you have just been redrawing the whole darn thing. It's just easier. U nfortunately, it is 

also quite costly. It means that you have to blit all the tiles that are in or partially in the screen space, even 
if it doesnt need redrawing. As І ме said before, the first rule is that you never blit when you dont have to, 
if you want good performance. 


So, concerning the additional frame buffer | ve been discussing, as | said earlier, it is an off-screen surface 
that is the same size as the screen space. Since the frame buffer is off-screen and does not flip, the image 
data on it remains consistent from frame to frame, which means that you know what's on it at any given 
time. By knowing what is on the frame buffer, you can then manipulate the image data into the new frame, 
usually without redrawing the entire thing. 


FRAME KUFFER SCROLLING 


T he first task I'm going to talk about for the frame buffer is scrolling. In any isometric game/ engine utili- 
ty, scrolling is a must. M ore than that, scrolling quickly is a must. H ave you ever played a game where the 
scrolling is slow or stuttered?Y ou know what | mean... you move the mouse to the side to scroll, and 
nothing seems to happen for a moment, and then you are suddenly halfway across the playing field. It’s 
annoying— you dont want to have something like that in your game You want to have a nice, smooth 
scroll. Sometimes it’s just not possible, especially with outdated video hardware and lower-end machines, 
but that’s no reason not to try! 


If you have static data on an off-screen surface, most of your scrolling is very easy. W hen you scroll, you 
can simply move a portion of the frame left, right, up, down— however the scroll is occurring. Figure 17.2 
depicts the area that is unaffected by а scroll to the right (unaffected meaning that it doesnt need to be 
totally redrawn). Н ence, you can use a large 81tFast to do the majority of your scroll, rather than the 
individual tiles. T hen you simply need to fill in the left edge of the image with new data to complete the 
current frame. A similar idea can be applied to left, up, or down scrolls. 
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Figure 17.2 


Scroll Direction: ToThe Right Bulk scrolling 


Area Affected Area Unaffected 
By Scrolling By Scrolling 


Previous Frame Current Frame 
(Stored in frame buffer) (BackBuffer) 


UPDATE RECTANGLES 


Ah, if only it were that simple! T he fact of the matter is that there very well could be portions of the 
area that do need to be redrawn. T here might be unit movement, animated objects, a tree added ог 
removed, or any number of things. T his is not a problem that will keep you from your task, however. 
You'll just have to get creative. 


Say, for instance, that there is a tile smack dab in the middle of that otherwise “unaffected” area that 
needs to be redrawn. You've worked too hard to go back to redrawing the entire frame. So, you wont. 
Instead, you will figure out what tiles need to be redrawn using the same method you used to selectively 
blit the tiles to the screen. You'll just use a smaller dipping rectangle. | told you that algorithm would 
come in handy! 


So, you'll do with this image what you did with the entire screen. You'll determine what rectangle to use 
for dipping, calculate where the corner tiles of the range are, and blit the tiles in that range. Simple 
enough, right? But where does that rectangle for clipping come from? You only know what tiles need to 
be updated. You have no idea how many neighboring tiles will be affected. You can figure it out, though. 


T he answer stems from the tiles themselves, Each one has its own extent necr, right? W el, you can safely 
assume that the most complicated thing you might do with all these images is blit every single one of them 
onto a single tile location. Youre looking at me like I'm crazy. I'm not. It's true, in this case, since you have 
only three tiles— the background, the shadow, and the tree. T rue, in a more complicated tile map, with 
hordes of objects, units, people, buildings, and so on, you probably wouldnt blit all of them to a single 
tile but I’m just pointing out the most extreme case. 
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If you blit every single Ше/ sprite to a single location, what is the smallest Rect that will contain them? 
Well, it's the union of all the extent кестѕ, offset by the screen space coordinates of the map location. 
M ake sense? 


So, you can go through all the tiles of all the tilesets and use Uni onRect to come up with the largest pos- 
sible extent for a given map location. Since your tilesets dont change, you can do this once, right after you 
load them, and just use that extent nec to figure out your update areas. N ow you can update small areas 
using your enhanced tile rendering algorithm, and you're doing fewer blits рег frame. All is right with the 
world. W ell, almost. 


Look at Figure 17.3, where | have placed some random areas for updating. W ith multiple update areas, 
you can just go through the list of update rectangles, rendering them as you go. H owever, you might not 
want to do that, and heres why. In the figure, rectangle А is fine, and you can just update it. R ectangles В 
and C, on the other hand, overlap. If you update each rectangle separately, the update for rectangles B and 
С will update at least one of the same tiles more than once. Rectangles D and E are yet another case. Parts 
of them lie outside the screen space. So, what to do? 


Figure 17.3 


Overlapping 
update areas 


In the case of D and E, the answer is simple. Just clip the update rectangles to the screen space, and then 
update as normal. Т he answer to В and С is not as simple О ne thing you might do is make a union from 
them. Н owever, that would cause additional tiles to be updated, which means you might as well just be 
updating the overlapping tiles twice. 


T he answer to the dilemma is not to immediately update the frame. Instead, somehow mark the map loca- 
tions for update T he easiest way to do this is to have an array of роот that has the same dimensions as 
the map array, and to have true indicate that a tile needs updating and ғат ѕе indicate that it does not. 
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T his way, when you add a кест to be updated, the same tile might be marked several times, but since you 
arent blitting yet, you wont be concerned. 


After all the update вест have been marked in this fashion, you can then scan the entire screen space 
using your rendering algorithm, but only draw those map locations that are marked for update. T his way, 
a given tile is drawn only once, which is what you want. T he way you have it set up now, the frame buffer 
still has the prior frame on it, and the back buffer has the effects of the scroll on it. W hen you updatethe 
tiles, you should write to the frame buffer, for reasons that will become clear in a moment. After you have 
updated all the tiles, you then blit each of the update кестѕ onto the back buffer so that the back buffer 
now has the complete current frame. Finally, blit the current frame from the back buffer to the frame 
buffer, and then go ahead and flip the primary surface. 


D o you see why you are updating to the frame buffer rather than the back buffer? It's because when 
updating, you are using the entire screen space as the clipping вест instead of the individual update 
RECTS, Because of this, you will have portions of tiles that spill outside the update rectangle, quite 
possibly obscuring other tiles. W hen you then move the update rectangles to the back buffer, you correct 
this problem. 


If you were paying close attention and thinking about overlapping update rectangles, you might have 
noticed that | just contradicted myself, .W hen you are blitting the update кестѕ from the frame buffer 
onto the back buffer, you will be blitting the overlapped portion twice. Before you yell “Н ypocrite"" and 
start getting out the pitchfork and torches, give me a chance to explain why I'm allowing this double blit- 
ting, but | wouldnt allow drawing the same tile twice It is a matter of simple arithmetic. Consider two 
overlapping update necs that, for the purposes of this example, have a single map location that needs to 
be updated for both. If you assume that this map location has a tree and shadow on it, and you update it 
twice, that is six blits (drawing the background, shadow, and tree each twice). H owever, if you update the 
map location only once that is only three blits. Add to this 2, because the same area is blitted because of 
the overlap, and that makes 5. T his means you've saved yourself one blit! Іп real situations, the facts 
become more complicated than what | just showed you here, but it's good enough to show you that I'm 
not just saying one thing and doing something different. 


AN ISOMETRIC RENDERING CLASS 


At last, l'm going to bring all the frame buffer stuff together and create a class that will minimize blitting 
using a frame buffer for scrolling and update rectangles. First, a decision must be made about what infor- 
mation such a class will need, based on the discussion so far. 


Right out in front, you know that а rendering class will need two LPDIRECTDRAWSURFACE7 Variables— one 
for the back buffer and one for the frame buffer. You will supply these two things to the class. For optimal 
tile updates, you need a cScroller, CMouseMap, CTileWalker, and CTilePlotter to do all the calcula 
tions for you. You will also supply these things to the class. You have to set them up anyway, 50 using 
pointers to them in another component isnt a big deal. Also, you'll need an extent вест, which you'll have 
to calculate based on all the tiles/ sprites in the application. T his might create а little bit of work for you 
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during initialization, but again, this is not a big deal. Since you'll be using update кестѕ, you need some 
way to store a list of вЕСТ5 in the dass. U nfortunately, you dont know how many RECTS are needed, so 
you should probably have some way to allocate a number of кестѕ that should be sufficient. Because you 
will rely on an array of boolean values to check whether to update a given map location, you need such an 
array in the class itself. Т he update array isnt needed anywhere but within the rendering class, so doing 
this is OK. Finally, you need a rendering function. T his will not be within the class itself, but rather a 
function that you create outside of the class and give a pointer to it to the renderer. T his will be just like 
what you do with your T ilePlotter and T ileW alker, only you must always supply the function rather than 
having it predefined. 


Н егес a summary of what you need in the way of members of your rendering class: 


= Two pointers to D irectD raw surfaces 

= Pointers to one of each 150Н exCore component 

= An extent rectangle used for calculating update RECTS 
= An update RECT buffer of arbitrary size 

= A boolean update array of arbitrary size 

= A pointer to a rendering function 


W hile were at it, | could certainly go for two turtledoves and a partridge іп a pear tree! 


For member functions, you should have nice friendly functions to set all the members of the class, like 

the frame buffer, back buffer, |soH exCore components, and so on. In addition, you should have functions 
to add update кестѕ to the update вест list, and a function to add a tile to the update вест list (the func- 
tion would use the extent вест and theT ilePlotter to figure out what вест is to be added). Also, you 
should have a function to do the bulk scroll and a function to update the frame (which blits all the update 
RECTS and resets the renderer for the next frame). 


W hen using the renderer, you should first call the scrolling member function, then add whatever update 
RECTS are necessary, and then call the update member function. T hat makes it pretty simple from your 
side. Because some of the algorithms you are using are quite complex, you definitely want to wrap them 
up in an easy-to-use class like this! 


BUILDING CRENDERER 


W ithout further delay, let's get to it. Go ahead and load up IsoH ех17 2.срр. In this example, | have 
supplied CRenderer in the files |soR enderer.h and IsoRenderer.cpp. 


T he code for cRenderer is the most complicated that | ve written so far. T his is because there are just so 
many things that have to be examined and calculated for it to work. T he declaration of cRenderer looks 
like the following: 


//CRenderer Declaration 
class CRenderer 
{ 
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public: 
/////////////////// 
//members 
ИИ B B Bl TTY 
//surfaces 
LPDIRECTDRAWSURFACE7 lpddsBackBuffer;//back buffer 
LPDIRECTDRAWSURFACE7 lpddsFrameBuffer;//frame buffer 
//isohexcore components 
CTilePlotter* pTilePlotter;//plotter 
CTileWalker* pTileWalker;//walker 
CMouseMap* pMouseMap;//mousemap 
CScroller* pScroller;//scroller 
//update RECT list 
RECT* rcUpdateList;//must be allocated 
int iUpdateRectCount;//number of RECTs in the update list 
int iUpdateRectIndex;//stores the next update RECT in the list 
//update map 
bool* bMap;//will be allocated with enough space for the entire map 
int iMapWidth;//width of the map 
int iMapHeight;//height of the map 
//extent rect 
RECT rcExtent;//extent rect, used when adding tiles to the update list 
//rendering function 
RENDERFN RenderFunction;//function used to render a tile 


///////////////////// 

//member functions 

///////////////////// 

//constructor 

CRenderer(); 

virtual ~CRenderer(); 

//destructor 

//surfaces 

void SetBackBuffer(LPDIRECTDRAWSURFACE7 lpdds); 
void SetFrameBuffer(LPDIRECTDRAWSURFACE7 lpdds); 
//isohexcore components 
void SetPlotter(CTilePlotter* pPlotter); 
void SetWalker(CTileWalker* pWalker); 
void SetMouseMap(CMouseMap* pMMap); 

void SetScroller(CScroller* pScroll); 
//update list 
void SetUpdateRectCount(int iMaxRects);//sets up the rectangle list 


ISOMETRIC GAME PROGRAMMING WITH, DIRECTX 7,0 


//update map 

void SetMapSize(int MapWidth,int MapHeight);//sets up the update map 
//rendering functions 

void SetRenderFunction(RENDERFN RendFunc) ; 
//extent rect 

void SetExtentRect(RECT* rcExt); 

//add rect to list 

void AddRect(RECT* prcAdd); 

void AddTile(int mapx,int mapy); 

//scroll the frame 

void ScrollFrame(int scrollx,int scrolly); 
//update the frame 

void UpdateFrame(); 


You can see that this class has far more members than any other class so far. Every single one of them is 
needed, too. CRenderer takes from you the task of having to calculate updates yourself. I'm going to 
briefly go over the parts of свепдегег.Т he actual implementation is something you can look at on 
your own. | dont have the space to go over it line by line here. 


RENDERFN 


T hereis one typedef for the cRenderer dass of which you should be aware. Since the entire operation of 
the dass depends on a user-defined rendering function for individual tiles, you need a function pointer 
type T his is supplied in the form of RENDERFN. Н ere is the declaration: 


//rendering function pointer typedef 
typedef void (*RENDERFN)CLPDIRECTDRAWSURFACE7 lpddsDst,RECT* rcClip, 
int xDst,int yDst,int xMap,int yMap); 


By now, you should be quite familiar with function pointer types. In the case of RENDERFN, there are six 
parameters, Table 17.4 lists these members and their meanings. 
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Table 17.4 RENDERFN Parameters 
Parameter Purpose 


lpddsDst The destination surface. In all cases, this will be whatever surface is 
being used as the frame buffer. 

rcClip A pointer to a clipping rectangle that will be passed along to 
whatever tilesets are used as the clipping ВЕСТ for calls to ClipTile. 

xDst The tile's screen x-coordinate. It is plotted by the renderer. 

yDst The tile's screen y-coordinate. It is plotted by the renderer. 

xMap The tilemap x-coordinate. 

yMap The tilemap y-coordinate. 


DATA MEMBERS 

Table 17.5 lists the data members of свепдегег and describes their basic purpose. In almost all cases, 
these members will be supplied by you— the programmer. [п the case of rcUpdateList and bMap, how- 
ever, you simply supply dimensions, and свепаегег does all the memory management for you. 
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Table 17.5 CRenderer Data Members 
Member Purpose 


lpddsBackBuffer Contains a pointer to the back buffer. Used for rendering. 
lpddsFrameBuffer Contains a pointer to the frame buffer. Used for rendering. 


pTilePlotter Contains a pointer to aTilePlotter. Used for calculations. 
pTileWalker Contains a pointer to aTileW alker. Used for calculations. 
pMouseMap Contains a pointer to a MouseMap. Used for calculations. 
pScroller Contains a pointer to a scroller. Used for calculations. 
rcUpdateList A buffer that contains a list of update RECTS. 


iUpdateRectCount Contains the total number of RECTS that can be stored in the 
update RECT buffer. 


iUpdateRectIndex An index into the update RECT buffer, indicating the next RECT 
to be assigned. 


bMap The update buffer, containing boolean values. It's true if a 
tile must be redrawn and false if it does not need redrawing. 

iMapWidth W idth of the update buffer. 

iMapHeight Height of the update buffer. 

rcExtent An extent rectangle to allow calculations of update RECTS 
based on map locations. 

RenderFunction A user-supplied rendering function. 


All of these members are public and thus can be examined at any time without the use of member func- 
tions. Also, this means that you can change the values of any of these members. W hile this "open" sort of 
dass design is very flexible and gives the programmer (you) alot of power, the fact remains that for the 
most part, you dont want to mess with the member functions except when initializing them. E specially 
stay away from rcUpdateList, bMap, and their related members. 


MEMRER FUNCTIONS 


T he member functions of cRenderer fall into two main categories: member access and utilization. T he 
member access functions serve a purpose similar to the initialization functions of the IsoH exCore 


components, meaning that you use them to set up the data members. Generally, you have to do initializa- 
tion only once. Т he utilization members, on the other hand, are used every frame. 
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MEMBER ACCESS FUNCTIONS 
T he member access functions of cRenderer аге listed in Table 17.6, alongside the data member(s) that 


they set or help calculate. M ost of these member access functions can be used multiple times without any 
problem, but certain ones cannot. I'll point them out to you so that you will be prepared. 


Table 17.6 CRenderer Member Access Functions 
Member Function 


Se 


Set 


Set 
Set 
Set 


Se 
Se 


tBackBuffer 


FrameBuffer 


Plotter 
alker 


ouseMap 


tScroller 


tUpdateRectCount 


SetMapSize 


SetRenderFunction 


SetExtentRect 


Purpose 


Sets the surface to use as the back buffer (1pddsBackBuffer 
data member). 


Sets the surface to use as the frame buffer (1pddsFrameBuffer 
data member). 


Sets a pointer to aTilePlotter (pTilePlotter data member). 
Sets a pointer to aTileW alker (pTileWalker data member). 


Sets a pointer to a MouseMap (pMouseMap data member). 
Sets a pointer to a scroller (pScroller data member). 


Allocates the update RECT list (rcUpdateList) and sets the 
size of the buffer (1UpdateRectCount). Sets iUpdateRect Index 
to 0. 


Allocates the update buffer (bMap) and sets the width and 
height of the update buffer (1Mapwidth and iMapHeight). 


Sets a pointer to a RENDERFN (RenderFunction). 
Copies a RECT into rcExtent. 


All but two of these member functions can be called any number of times without detrimental effects. 
T he two oddballs, setUpdateRectCount and SetMapSize, should not be called more than once W hy 


not? Because they deal with memory allocation. If called more than once, they will allocate memory twice, 


without ever deleting the memory that is no longer used. T his means you are leaking memory, which is, on 


the good-bad scale of things, a bad thing. T here is no great secret to using the member access functions. 
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W ith the exception of SetMapSize, they all take a single parameter. SetMapSi ze takes two. Т hese member 
functions are pretty much common sense. 


UTILIZATION MEMBER FUNCTIONS 


After 14 data members and 10 member access functions, you might expect there to be approximately the 
same number of functions to make use of the class on a frame-by-frame basis. Instead, there are only four, 
one of which is called only very rarely. Table 17.7 lists these functions and their purpose. 


Table 17.7 CRenderer Utilization Functions 


Function Purpose 

AddRect Adds an update RECT to the update list 

AddTile Uses a map location to calculate and add an update RECT 
ScrollFrame Scrolls the frame 

UpdateFrame U pdates the frame 


It’s hard to believe, but that's all there is to the cRenderer dass. Н eres the basic operation per frame 


1. Scroll the frame using Scrol1 Frame. 

2. Add any necessary update RECTS and update tiles that need it using AddRect or AddTile. 
3. Update the frame using UpdateFrame. 

4. Flip the primary surface. 

5. Go make yourself a sandwich. W hile you're at it, make me one, too. I’m kind of hungry. 


| wont go into the ugly details of cRenderer’s implementation here. It would easily take up 50 pages or 
so, and neither of us has that kind of time. Suffice it to say that CRenderer bases most of its code on the 
more efficient blitting algorithm that was developed in Chapter 16, “Layered M aps and O ptimized 
Rendering" Every time AddRect is called, that RECT is scanned using that algorithm, and the tiles it 
encompasses are marked for update. W hen Adari1e is called, the coordinates for the tile are used to offset 
the extent RECT, and the result is sent to AddRect. Scrol1Frame does a bulk scroll and adds two update 
ВЕСТ to the list: one for the x scroll and one for the y scroll (and no, the update весте do not overlap). 

T he update frame is what does the real work, scanning the entire screen space for marked tiles and sending 
the information to the rendering function. 
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A CRENDERER EXAMPLE 
Even though I’m not sharing the nitty-gritty details of how | implemented cRenderer, | will show you 


how | built an example that uses it. 150Н ех17 2.срр is the example in question. T his example uses 
CRenderer, which requires the addition of some global variables. 


О пе extra global exists in the form of LPDIRECTDRAWSURFACE7. N атау, this is your frame buffer. D uring 
Prog_Init, | create an off-screen plain surface that is 640 pixels wide and 480 pixels tall (the same size as 
the back buffer). T he other main extra global is an instance of cRenderer, which | have named, of all 
things, “Renderer.” 


INITIALIZATION 


T he main change in 150Н ех17 2.срр from [50Н ех17 1.срр is that you have the extra surface 
(1pddsFrame) and the cRenderer (Renderer). Initializing the frame buffer is a simple one-line deal: 


//create 


the frame buffer 


lpddsFrame-LPDDS CreateOffscreen(1pdd,640,480); 


W oo hoo! 
before you 


Н ooray for the ооғипсѕ library! It makes surface creation not only easy, but fun, too. H owever, 
can initialize the renderer, first you need to calculate the extent кест from all your various tile 


images. T his is a simple application of UnionRect, which is as follows: 


//calculate the extent rect 


//set to 
CopyRect 


RECT rcExtent; 


background extent 
(&rcExtent,&tsBack.GetTilelList()[0].rcDstExt) ; 


//union with shadow extent 
UnionRect(&rcExtent,&rcExtent,&tsShadow.GetTilelist()[0].rcDstExt) ; 
//union with tree extent 
UnionRect(&rcExtent,&rcExtent,&tsTree.GetTilelist()[0].rcDstExt) ; 


Pretty easy, | think. First, copy the extent of the background image into your temporary rcExtent vari- 
able, and then use UnionRect to merge this with the extent вЕСТ$ from the shadow and tree image. If you 
had more tiles/ sprites, you would just loop through them here. To speed up the process, you might decide 
to add a new member function to стітеѕе+ that takes a union of all the extents in the set. Just an idea. 
Finally, you initialize all the data members of Renderer, using the member access functions | spoke of ear- 


lier. 
//set up 
Renderer 


Renderer 
Renderer 


the renderer 
.SetBackBuffer(lpddsBack); 
.SetExtentRect(&rcExtent); 
.SetFrameBuffer(lpddsFrame); 
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Renderer.SetMapSize(MAPWIDTH,MAPHEIGHT) ; 
Renderer.SetMouseMap(&MouseMap) ; 
Renderer.SetPlotter(&TilePlotter); 
Renderer.SetRenderFunction(RenderFunc); 
Renderer.SetScroller(&Scroller); 
Renderer.SetUpdateRectCount(100); 
Renderer.SetWalker(&TileWalker); 

//update the entire screenspace 
Renderer.AddRect(Scroller.GetScreenSpace()); 


T his bit of code just goes down the list of member access functions, setting then to appropriate values 
as you go. | used theVisual C++ 6 Intellisense to go alphabetically. For safety, | set the update rectangle 
buffer to 100 кестѕ, even though with your simple application, you will never have more than a few 
update rectangles. 


A brief note about update recTs: You will never need a huge number, since the highest number of кестѕ 
that need updating is the number of tiles that make up the entire screen, plus two necrs for scrolling. 
Currently, your screen takes up about 12x32 tiles, if you count the border tiles. H ence, you could 

set the update вест buffer to 500 кестѕ, and you shouldnt have to worry too much about overflow if 
you're careful. 


T he final line of the code snippet sends an update вест for the entire screen. Т his is important, because 
initially the frame buffer is empty and needs to be totally redrawn, 


CLEANUP 
T here is one extra line in the cleanup section of the program. T his line releases the frame buffer surface. 


//release frame buffer 
LPDDS_Release(&lpddsFrame) ; 


T he renderer cleans up after itself after the program terminates. 


MAIN LOOF 


Ah, finally the main loop! It's actually quite simple compared to the code found in IsoH ех17 1.срр, since 
all of the hard stuff has been moved to the cRenderer implementation. 


void Prog_Loop() 

{ 
//grab the mouse position 
POINT ptMouse; 
GetCursorPos(&ptMouse) ; 
//map the mouse 
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ptCursor=MouseMap.MapMouse(ptMouse) ; 

//clip the cursor to valid map coordinates 
if(ptCursor.x«0) ptCursor.x=0; 

if(ptCursor.y«0) ptCursor.y=0; 
if(ptCursor.x>(MAPWIDTH-1)) ptCursor.x=MAPWIDTH-1; 
if(ptCursor.y>(MAPHEIGHT-1)) ptCursor.y=MAPHEIGHT-1; 


You've seen this code before. It grabs the position of the mouse and uses the М ouseM ap to calculate 
where the cursor is. 


//scroll the map 
Renderer.ScrollFrame(ptScroll.x,ptScroll.y); 


As you'll recall from earlier examples, ptScro11 is set during wM_MOUSEMOVE, and it indicates how far you 
are to scroll the map in each frame. Rather than scrolling yourself, as you did in earlier examples, you pass 
the task of scrolling to Renderer and allow it to do its job. 


//if a click was registered, add an update tile 

if (bClick) 

{ 
Renderer.AddTile(ptCursor.x,ptCursor.y); 
iMap[ptCursor.x][ptCursor.y]=1-iMap[ptCursor.x][ptCursor.y]; 


} 
//set click to false 
bClickefalse; 


T his is a change from earlier examples. Before, when responding to wM_LBUTTONDOWN, you would change 
the contents of the map location at the cursor. Using CRenderer, you cannot do that, because doing so 
before the scroll will mess up the update вест, and artifacts will result. To solve this problem, | made a 
new global variable (bc1ick) that is set during им_гвиттомосим. In this code snippet, | check to see if 
bClick Is being set. If it is, only then do | update the map and add an update вест to the renderer. T his 
ensures that what needs to be rendered will be rendered. T hen | reset pc1ick to false to await another 
WM. LBUTTONDOWN. 


//update the frame 
Renderer.UpdateFrame(); 


If you've looked at свепаегег5 code, you know just how much work is being done by this single line. 
H ere, you update the frame buffer and the back buffer and prepare for the next frame. 


//plot the cursor 
POINT ptPlot; 
ptPlot-TilePlotter.PlotTile(ptCursor); 
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ptPlot=Scroller.WorldToScreen(ptPlot); 
tsCursor.ClipTile(lpddsBack, Scroller.GetScreenSpace(), ptPlot.x, 
ptPlot.y, 0); 


Youve seen code similar to this in prior examples. T his is the “place the cursor on the back buffer" code. 
Since you only put the cursor on the back buffer, and not on the frame buffer, you don't have to worry 
about erasing it later. 


//flip to show the back buffer 
lpddsMain-»Flip(O,DDFLIP WAIT); 


Finally, you flip the primary surface, and your loop is complete. T heonly thing left to show is the actual 
rendering function. 


void RenderFunc(LPDIRECTDRAWSURFACE7 lpddsDst,RECT* rcClip,int xDst,int yDst,int 
xMap,int yMap) 
{ 
//put background tile 
tsBack.Cliplile(lpddsDst,rcClip,xDst,yDst,0); 
//check for a tree 
if(iMapLxMap]LyMap]) 
{ 
//put shadow 
tsShadow.ClipTile(lpddsDst,rcClip,xDst,yDst,0); 
//put tree 
tsTree.ClipTile(ClpddsDst,rcClip,xDst,yDst,0); 


Looks а lot like the inner part of the rendering loop from 150Н ех17 1.срр, doesnt it? It should because 
it is, with a few minor changes like the removal of code using {пет ilePlotter and scroller. Т his is the 
function you send to Renderer. It is called during UpdateFrame() for as many tiles as need redrawing. 


So, you have now drastically simplified your life by encapsulating your rendering within cRenderer, and 
it's now faster to boot. Н ow much faster depends on your computer and video card, but | can tell you that 
on mine, the scrolling certainly became a lot smoother as a result. If your machine or video card is lower- 
end, you might not notice a difference (it'll be just as choppy either way). Also, if your machine and video 
card are sufficiently high-end, you wont see much of a difference either (it'll be just as smooth, even if 
you're using the less-efficient method). T hat's just hardware for you. 
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SUMMARY 
CRenderer will be around for the rest of the book, at least until you start to delve into Direct3D. 
Crenderer is handy, it's fast, and it encapsulates a lot of otherwise very ugly code. 


You probably have noticed that as you've built the various components of your isometric engine, you've 
gotten further away from the raw calculations that make it work. T his is a good thing. It means that you 
have added power and flexibility and that you can adapt your engine to whatever task you can imagine 
without having to redo anything you hard-coded. 


I've taken rendering optimization about as far as DirectX will let me Sure, there are still optimizations you 
can do, using Lock/Unlock and rendering things yourself, but that's beyond the scope of this book. 

H owever, if you do come up with an interesting optimization, be sureto drop me a line and let me know. 
l'm always interested in increasing performance, and many people! talk to think of things that | might 
not, and vice versa. 
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Орест PLACEMENT AND MOVEMENT 


d like to extend to you a hearty congratulations for making it through Chapter 17.T here were 
moments when | thought | wasnt going to get through it. Believe it or not, the preceding chapter 
contained about the most complicated code in the entire book. T his isnt to say I'm going to let you coast 

through the rest! Plenty of challenges await you. 


T his chapter is about object selection and movement. I'm going to discuss the objects (units, items, obsta- 
des) that inhabit your isometric worlds. You started down this path in Chapters 16 and 17, but I'm pretty 
sick of looking at that darned tree, and | think that you are too. 


OBJECT PLACEMENT 
(СОР versus FOP) 


T his next sentence might sound like common sense, but bear with me. Before you can get into object 
Selection, the objects must first be somewhere. W hile you cursing me for saying something so idiotic, let 
me say that I'm not really talking about where the objects are placed, but rather how they are placed. 


Basically, there are two ways to place objects. О ne way is to say that in a given map location, an object fills 
the entire map location. So, if map location (15,15) contains a mountain, and you are moving your cavalry 
unit there, and the rules state that cavalry units cannot move onto mountains, the move is disallowed, and 
the unit must stay outside map location (15,15). W ith this type of object placement, all the objects within 
а given location take up the entire location. T herefore, collision detection is very simple, because all moves 
can be considered to be from the center of one location to the center of an adjacent location. T his type of 
object placement is common in turn-based strategy games, which by their nature are more abstract. | call 
this method coarse object placement. 


T he other type of object placement is fuzzier. O bjects do not necessarily take up the entire map location, 
and they might or might not be positioned at the centers of locations. Т his type involves much more 
work, and it complicates things. First, you have to do collision detection, through either bounding rectan- 
gles or bounding ellipses. Second, the rendering is more complicated, because several different objects 
might be occupying a location or a portion of a location, so you have to figure out in which order to blit 
the images. T his method adds realism, since it makes it harder to tell whether the world is tile based, even 
though the overhead that can be introduced by this method can easily degrade performance. Т his is the 
method most commonly used by real-time strategy games. | call it fine objet placement. 


Both methods have their pluses and minuses when used in their pure forms. Generally speaking, you will 
want to use coarse object placement when making turn-based strategy games and fine object placenent 
when making real-time strategy or role playing games. 


1S0OMETRIC GAME PROGRAMMING WITH, DIRECTX 7,0 


H owever, most real-time strategy games use a sort of hybrid methodology, perhaps using coarse object 
placement to place buildings and structures and such and using fine object placement for units. Like 
most things, there is no one true way. You have to consider the needs of your game before making a 
decision either way. 


COARSE OBJECT PLACEMENT 


Let's say, for the moment, that you have decided to use coarse object placement in your game. Т his deci- 
sion has some far-reaching ramifications for the methods you use within your game for object selection and 
movement, mainly making both pretty easy, but some extra difficulties with a useful display echo occur. 
(For example, you have to do some extra work for everything to look OK and to be able to size up your 
situation at a glance.) 


IYloOviNG OBJECTS AROUND 


You've already done coarse object placement with the little tree image, so | wont bore you by explaining 

it again. Suffice it to say that you just need to accommodate each object in the map structure somehow. 
Inanimate objects, like trees, fortifications, roads, and rivers, should be handled separately from units, since 
you can have both an inanimate object and a unit on the same tile. 


It's example time! Load ир IsoH ех18 1.cpp. In this example, I've provided a single unit/ character that 
will move around the map (almost the same as the map from Chapter 17). T his unit/ character is shown 
in Figure 18.1. IsoH ех18 1.cpp is quite a bit like IsoH ех17 2.cpp, just with most of the mouse scrolling 
ripped out and keyboard control placed in. 


Figure 18.1 


An example of 
a unit/character 
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Figure 18.2 shows what this example looks like when | run it on my machine After you press 6 on the 
numeric keypad (with N um Lock engaged), it looks like Figure 18.3. Finally you have something on your 
screen that isnt background terrain or a darned tree! Go ahead and move the unit around the map. R ight 
now, the way it works is less than ideal, but at least it's something. 


Figure 18.2 
IsoHex18 1.срр on startup 


Figure 18.3 


ІѕоН ех18 1.cpp after a 
move to the east (right) 
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W hat do | mean by “less than ideal"? W dll, for one thing, when the unit moves from one location to 
another, it just "jumps" suddenly. O ne moment it's in the original map location, and the next, it's in the 
new one, like magic. For some games this might be O K, but in most, you dont want to do this, lest the 
player get vertigo or go into epileptic fits. We'll get to a more smooth movement in a few minutes. 


Another aspect of IsoH ех18 1.срр is the manner in which it scrolls. В ather than using the mouse to 
scroll, the display is scrolled whenever the unit passes the screen boundary (that is, when x<0, у<0, 
x>=SCREENWIDTH ОГ y»-SCREENHEIGHT). W hen one or more of these thresholds are crossed, the display 
jumps up/ down/ left/ right by half a screen (320 pixels for left or right and 240 pixels for up or down). 
Figure 18.4 shows the "before" picture, and Figure 18.5 shows the "after" picture T his isnt the only way 
| could have done it, and in fact, it wasnt the only way | did it. At first, | had the display centered on the 
unit at all times. Talk about jumpy and disconcerting! 


Figure 18.4 


Just before a 
major scroll 
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Figure 18.5 


Just after a major scroll 


№ aturally, youd like me to just shut up and show you the code, right? Of course. 


THE CODE 


As I said earlier, IsoH ех18 1.cpp is based on IsoH ех17 2.cpp, meaning that cRenderer is being used. 
Since the program is quite long, | will just highlight the big changes and leave it at that. 


GLOBALS 


T he first changes occur in the section of code where all the globals are declared. T he code doesnt use all 
the same tilesets (| got rid of the shadow and the cursor), and | added a new tileset with the unit's image. 
T he global tilesets are as follows: 


//tilesets 

CTileSet tsBack;//background 
CTileSet tsTree;//tree foreground 
CTileSet tsUnit;//unit 


T he tsBack and tsTree objects contain the tilesets for the background tile and the tree (cant get away 
from that tree!) T he tsunit object contains the image for our nifty new unit. N ext is an addition to the 
global section rather than a change T he following is all of the global variables needed to keep track of our 
unit's position, direction of movement, and whether or not it is moving. 


//keep track of unit location 
POINT ptUnit;//current position of the unit 
POINT ptUnitOld;//last position of the unit 
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ISODIRECTION idMoveUnit;//direction of movement 
bool bMoveUnit;//the unit should be moved 


ptUnit keeps track of the unit's current position. ptUnit01d keeps tabs on the unit's last position (since 
you have to update both where the unit was and where the unit is when the unit is moved). idMoveUnit is 
ап ISODIRECTION specifying in which direction to move the unit. Finally, bMoveUnit is a boo! that is true 
when you move the unit and false when you dont. 


T he last change to the global section is how the map is represented. As you might recall, in most of the 
last two chapters’ examples, it was a simple two-dimensional array of ints, with 0 being no tree and 1 
being a tree. Since a unit has been added to the mix, the map structure gets more complicated, but not 
overly so, because this is still quite a simple stage. 


//map location structure 
struct MapLocation 
{ 
bool bTree;//false-no tree; true=tree 
bool bUnit;//false=no unit; true=unit; 
}; 
MapLocation mlMap[LMAPWIDTH]LMAPHEIGHT];//map array 


T he struct named MapLocation contains two members, bTree and bunit. T hey control what is on a 
given tile (At this point, all tiles have the same background, so they are not represented in the map struc- 
ture) T he new array, m1Map, gives you a large-enough map to work with. It's mostly the same as previous 
sample programs, other than the type. 


INITIALIZATION 


М ost of Prog Init is the same as in previous examples. Т he images get loaded into their respective tileset 
variables, and the CRenderer extent RECT is calculated from all tilesets. T he initialization of the 
IsoH exC ore components is mainly the same Т he first change occurs when you initialize the map. 


//set up the map to a random tilefield 
for(int x=0;x<MAPWIDTH; х++) 
{ 


for(int y=0;y<MAPHEIGHT; y++) 

{ 
mlMapLx]ly].bTree=((rand()%2)==1);//random tree 
mlMapLx]ly].bUnit=false;//no unit 
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| admit it— this isnt a really big change Т his change occurred for the simple reason that the map structure 
changed from being int-based to being MapLocation-based. 


N ow for something important: the unit's initial placement. l'm going to explain as | go, because it's too 
long to explain all at once. 


//set the position of the unit 
ptUnit.x=rand()%MAPWIDTH; 
ptUnit.y=rand()%MAPHEIGHT ; 


T he idea here is that you want the unit to start on a random map location, so take random numbers based 
ОП MAPWIDTH and MAPHEIGHT and assign them to ptUni t. 


ptUnitOld-ptUnit;//set the old position to the same position 
mlMapLptUnit.x][ptUnit.y].bUnit=true;//set the unit on the map 
bMoveUnit-false;//set unit movement to false 


Since you are keeping track of the old unit position, you have to initially assign the old unit position to 
the current position. М ext, place the unit by setting the correct map location's punit member to true. 
Finally, you set bMoveUnit to false so that you wont start out with a moving unit. 


//plot the position of the unit 

POINT ptPos-TilePlotter.PlotTile(ptUnit); 
ptPos.x--(Scroller.GetScreenSpaceWidth()/2);//center the unit horizontally 
ptPos.y--(Scroller.GetScreenSpaceHeight()/2);//center the unit vertically 
//set the anchor 

Scroller.SetAnchor(&ptPos); 

Scroller.WrapAnchor(); 


T his is where the code gets a little weird. Initially, | wanted to have the unit centered on the screen, if 
possible. Since you have the rather spiffy 150Н exCore components to do the work for you, this is a simple 
matter of setting the anchor location. So, | plotted the position of the unit, and from that location, sub- 
tracted half of the screen width from x and half of the screen height from y to give me the position of 
the upper-left corner, which | then assigned to the anchor. Таке a moment and consider what kind of 
work you would have to do if you didnt have the 150Н exCore components. M akes me shudder just to 
think about it! 


MAIN LOOP 


Despite its length, the Prog_Loop is pretty simple. It mainly deals with movement of the unit whenever 
it occurs. Let's go over it piece by piece. 


void Prog Loop() 
{ 
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//set scroll to 0,0 
ptScroll.x-0; 
ptScroll.y=0; 


First, you have to make sure that the scrolling is set to Os. If the unit is being moved, this might be 
changed a little later on. T hese two lines of code just ensure that if there was a scroll last frame, there isnt 
one this frame. 


//if we are to move the unit 
if (bMoveUnit) 
{ 
//calculate the next position of the unit 
POINT ptNextPos=TileWalker.TileWalk(ptUnit,idMoveUnit); 
//bounds checking 
if(ptNextPos.x«0) bMoveUnit=false; 
if(ptNextPos.y<0) bMoveUnit=false; 
if(ptNextPos.x>=MAPWIDTH) bMoveUnit=false; 
if (ptNextPos.y>=MAPHEIGHT) bMoveUnit=false; 


As stated earlier, bMoveUnit is true when you move the unit and false when you dont. Also, idMoveUnit 
is the direction of movement. In this snippet of code, you calculate the next position for the unit by using 
theT ileWalker. After that is done, the code performs a few checks to make certain that the new position is 
still within the map. If the new position is not within the bounds of the map, bMoveUnit is set to false, 
thus canceling the move. 


//are we still moving the unit? 

if (bMoveUnit ) 

{ 
//set the unit position to ptnextpos 
ptUnit=ptNextPos; 

//plot the unit’s next position 

POINT ptPlot=TilePlotter.PlotTile(ptUnit); 
//translate plot position into screen coordinates 
ptPlot=Scroller.WorldToScreen(ptPlot); 

//check for scrolling 

if(ptPlot.x«0) ptScroll.x--320; 

if(ptPlot.y«0) ptScroll.y--240; 

if(ptPlot.x>640) ptScroll.x-320; 

if(ptPlot.y>480) ptScroll.y=240; 
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If bMoveunit is still true after the bounds checking, you set up the unit's movement and any scrolling that 
might be required. T he unit's position (stored in ptunit) is set to the new calculated position. T hen the 
unit's position is plotted using theT ilePlotter and is translated into screen coordinates by the scroller. 

If the plotted position is outside the screen, ptscro11 1$ set to an appropriate scrolling value. 


//scroll the map 
Renderer.ScrollFrame(ptScroll.x,ptScroll.y); 


T his line performs whatever scrolling you might require. M ost of the time, this will be none, so it will 
just copy from the frame buffer to the back buffer the entire image using the renderer. 


//if we are still moving the unit 
if(bMoveUnit) 
{ 

//reset the old position 
miMap[ptUnitOld.x][ptUnitOld.y].bUnit-false; 
//set the new position 
miMap[ptUnit.xJ][ptUnit.y].bUnit-true; 
//add update tiles to renderer 
Renderer.AddTile(ptUnitOld.x,ptUnitOld.y); 
Renderer.AddTile(ptUnit.x,ptUnit.y); 

//set moveunit to false 
bMoveUnit-false; 

//set old position to current position 
ptUnitOldeptUnit; 


Finally, you actually move the unit. Reset the bunit member of the map location at ptUnitoid and se 
the bunit member of the map location at ptunit. T hen send the ptunit01d and ptunit positions to the 
renderer to be updated. Last, set bMoveUnit to false (you are done moving now) and set ptunito1d to the 
current unit position, ptunit. 


//update the frame 
Renderer.UpdateFrame(); 

//flip to show the back buffer 
lpddsMain-^Flip(O,DDFLIP WAIT); 


Last, tell the renderer to update the frame and then flip the primary surface. N ote that there is absolutely 
no rendering code of any form inside Prog Loop. All rendering is done through cRenderer, 

SO you can concentrate on just figuring out what changes from frame to frame, and just deal with that. 
Very liberating, really. 
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RENDERING FUNCTION 
All the rendering work is done through cRenderer and hence through RenderFunc. 


void RenderFunc(LPDIRECTDRAWSURFACE7 lpddsDst, RECT* rcClip, int xDst, int yDst, 
int xMap, int yMap) 
{ 


//put background tile 
tsBack.ClipTile(lpddsDst,rcClip,xDst,yDst,0); 
//check for a tree 
1Е( т] Мар[хМар ][УМар].БТгее) 
{ 
//put tree 
tsTree.ClipTile(lpddsDst,rcClip,xDst,yDst,0); 
} 
//check for the unit 
if(mIMap[xMap]LyMap].bUnit) 
{ 
//put unit 
tsUnit.ClipTile(lpddsDst,rcClip,xDst,yDst,0); 


H ow simple can you get? First, you render the background tile from tsBack. N ext, If bTree is set at 
(хМар,уМар), you render the tree from tsTree. Finally, if punit 15 true, you render the unit. 


EVENT HANDLING 


М ainly, you are only concerned with им кғуроим, since you are controlling the unit with the keyboard. 
You can take a look at the code if you like Table 18.1 shows the ук_* constants | used and the correspon- 
ding ISODIRECTION values. 
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Table 18.1 Virtual Keycode-to-ISO DIRECTION 


Mapping 

Virtual Keycode Direction 

VK NUMPAD8 IS0, NORTH 

VK NUMPAD9 150_МОВТНЕА$Т 
VK_NUMPAD6 ISO, EAST 

VK NUMPAD3 150 SOUTHEAST 
VK NUMPAD2 IS0, SOUTH 

VK NUMPADI ISO_SOUTHWEST 
VK_NUMPAD4 150_МЕЗТ 
VK_NUMPAD7 ISO NORTHWEST 


SMOOTH SLIDING 


Sample program IsoH ex18_1 is pretty cool, NOTE 


but it probably leaves you lacking. | agree, but 
it’s just a simple example illustrating basic unit 
movement; your vision of unit movement prob- 
ably far exceeds its capabilities. First, it has only 
a single unit, which is great for illustrating an 
example, but it has rather limited use. Second, 
the movement is too... abrupt. It’s like the unit 
is teleporting from one map location to anoth- 
ег. Оп a purely aesthetic bent, the unit is taller 
than the tree, so it looks unrealistic. 


The virtual keycodes listed in Table 18.1 work 
only when the Num Lock is engaged. If you 
wanted to respond to the keypad when the 
Num Lock is off, you would have to respond 
to the arrow keys (VK. LEFT, VK RIGHT,VK UP, 
VK DOWN) and the document navigation keys 
(VK. HOME, VK END, VK PAGEUP, VK_PAGEDOWN). 
For a simple example like this one, I felt it 
unnecessary to do this, but in a professionally 
done game, you'd want to have that feature. 


It would be preferable to have the unit either slide from one map location to the next or go through an 
animated sequence of images from one tile to another. T his will bea bit of work, considering how the 
CRenderer Class is set up, and because of the overlapping nature of isometric tiles. Fear not. We are cre 
ative, and we shall overcome all obstacles! (A positive attitude will take you far.) 


T he next example, which will be revealed in just a moment, slides the unit from one tile to the next, mak- 
ing smaller movements per frame. | figure that four frames to make а move is more than adequate to make 
it look like you are sliding the piece. Plus, 4 goes into 64 (the tile width) and 32 (the tile height) evenly. 
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For an even smoother slide, you could use eight frames, and for a very quick slide, you could use only two. 
You'll use four in the example, although adapting this method to use other numbers is a simple matter. 


Table 18.2 shows the changes in screen/ world coordinates for the various isometric directions, based on 
the 64x32 tile It also shows the change in x and the change in y divided by 4.T his table is just a rehash 
of T ilePlotter information. It's nothing new. 


Table 18.2 Pixel-Scale Movement 
Direction ChangeX ChangeY ChangeX/4 СһапдеҮ/4 


North 0 -32 0 -8 
Northeast +32 -16 +8 -4 
East +64 0 +16 0 

Southeast +32 +16 +8 +4 
South 0 +32 0 +8 
Southwest -32 +16 -8 +4 
W est -64 0 -16 0 

N orthwest -32 -16 -8 -4 


T he basic idea here is that when a user presses а key, indicating that the unit is to be moved, the unit's 
world/ screen position will be changed by ChangeX / 4 and ChangeY / 4 during the next four frames. 


Ah, if only it were that simple! U nfortunately, problens ensue because of the tile overlap. For example, 
let's say that you want to move your unit to the south. If, for the moment, the unit remains in its original 
map location, and you change x and y each frame by the values in Table 18.2, after the bottom of the 
unit's image is below the bottom of the backgrounds tile image, it will be partially obscured by other tiles 
that are “in front” of the original position. Similarly, you cannot move the unit to its new location and 
offset from that, because in half of the cases, the same thing happens. Of the two positions for the unit, 
the starting location and the ending location, during the move you want the unit to be associated with the 
location that is rendered last. 


W ithout further ado, load up IsoH ех18 2.срр.Т his example, which is based on IsoH ex18 1, demon- 
strates smooth sliding. Figure 18.6 shows one such slide in the middle of making it happen. Because of 
the method | am using, there are certain visual inconsistencies when an object moves. For example, in 
Figure 18.6, the unit is shown after the tree that would otherwise be “in front” of it. Of course, you prob- 
ably wouldnt notice these inconsistencies, because the unit moves too fast for you to notice them. 
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Figure 18.6 


Smooth sliding demo 


Let's take a look under the hood, shall we? 


GLOBALS 


M ost of the globals in IsoH ех18 2 are the same as іп IsoH ех18 1. A few were added to accommodate 
the smooth scrolling nature of unit movement. 


//game state 
int iGameState=GS_IDLE; 


T he first of these new globals is iGameState. Unfortunately, the smooth scrolling algorithm is just too 
complicated to do іп a single game state. T here are four game states, as shown in Table 18.3. 


Table 18.3 Game States 


State When It Happens 

GS_IDLE Most of the time (when no movement is happening) 
GS_STARTMOVE W hen a key is pressed 

GS_DOMOVE During a move 


GS DONEMOVE W hen a move has finished 
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Figure 18.7 


IsoHex18 2 game 
states 


Framecounter -4 


M ost of the time, the application sits around in Gs_IDLE, waiting for a key to be pressed. Figure 18.7 
shows the flow of the program from game state to game state. 


//unit offset 
POINT ptUnitOffset; 
int iUnitFrame=0; 


T hese two little variables control how the unit is “slid” across the map. T he x and y components of 
ptUnitOffset are added to the unit's plotted position during the RenderFunc. Т he iUnitFrame variable 
keeps count of how many frames of the move have occurred. If it hits four, the move is finished. 


INITIALIZATION/ CLEANUP 
In this example, the initialization code and cleanup are identical to 150Н ех18 1. N o changes are necessary. 


MAIN LOOP 


T he main loop, on the other hand, has changed a great deal, especially because of the switch to multiple 
game states. L e's look at them one at a time. 


(35. ТОЕ, 


M ost of the time, the application sits in GS_IDLE (sort of like being in neutral for a car). T he code for 
it is rather simple. 
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case GS_IDLE://the game is idling; update the frame, but that’s about it. 
{ 
//scroll the frame (0,0) 
Renderer.ScrollFrame(0,0); 
//update the frame 
Renderer.UpdateFrame(); 
//flip to show the back buffer 
lpddsMain-»Flip(O,DDFLIP WAIT); 
}break; 


As you can see, not much is going on here Т he code shown is the bare minimum required to update the 
frame and flip the primary surface. N o big deal. 


GS_STARTMOVE. 


At any time during as_1DLe, if a numeric keypad key is pressed, a direction is placed in idMoveunit, and 
the game state is set to 05 sTARTMOVE. GS_STARTMOVE does not update the display; it simply sets things up 
so that the move can be performed. 


case GS STARTMOVE: 
{ 
//remove the unit from the old position 
mlMap[ptUnitOld.x][ptUnitOld.y].bUnit-false; 


First, you remove the unit from its old position, even though there is a 50-50 chance that you'll place it 
right back there. 


//calculate new position (virtual new position) 
switch(idMoveUnit) 


case ISO NORTH: 
case ISO NORTHEAST: 
case ISO NORTHWEST: 
case ISO WEST: 

{ 


//move ptUnit 

ptUnit=TileWalker.TileWalk(ptUnit,idMoveUnit) ; 

//set the offset 

ptUnitOffset.x-0; 

ptUnitOffset.y-0; 

//place unit at old position 

mlMap[ptUnitOld.x][ptUnitOld.y].bUnit-true; 
}break; 
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Depending on the direction stored in idMoveUnit, you se up the ptunitoffset and place the unit on 
either the starting or ending location, depending on which location is rendered last. If the direction is 
north, northwest, northeast, or west, you leave the unit at its old position and set ptUnitoffset to (0,0). 
Take a look at Figure 18.8, which shows the rendering order of the original tile (the one in the center of 
the figure) and its eight neighbors. T he original tile is shaded darkly, and the neighbors rendered before the 
center tile are lightly shaded. T his is why for the four directions | just listed, you must leave the unit on the 
original tile— at least for the time being. 


Figure 18.8 


Rendering order 
of neighboring 
map locations 


case ISO EAST: 
{ 
//move ptUnit 
ptUnit=TileWalker.TileWalk(ptUnit,idMoveUnit); 
//set the offset 
ptUnitOffset.x=-64; 
ptUnitOffset.y-0; 
//place unit at new position 
mlMap[ptUnit.x][ptUnit.y].bUnit-etrue; 
}break; 
case ISO_SOUTHEAST: 
{ 


//move ptUnit 
ptUnit=TileWalker.TileWalk(ptUnit,idMoveUnit); 
//set the offset 

ptUnitOffset.x--32; 
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ptUnitOffset.y--16; 
//place unit at new position 
mlMap[ptUnit.x][ptUnit.y].bUnit-true; 


}break; 
case ISO SOUTHWEST: 
{ 
//move ptUnit 
ptUnit=TileWalker.TileWalk(ptUnit,idMoveUnit) ; 
//set the offset 
ptUnitOffset.x-32; 
ptUnitOffset.y--16; 
//place unit at new position 
mlMap[ptUnit.xJ][ptUnit.y].bUnit-true; 
}break; 
case ISO_SOUTH: 
{ 


//move ptUnit 
ptUnit=TileWalker.TileWalk(ptUnit,idMoveUnit) ; 
//set the offset 
ptUnitOffset.x-0; 
ptUnitOffset.y--32; 
//place unit at new position 
mlMap[ptUnit.x][ptUnit.y].bUnitetrue; 

}break; 


T he rest of the directions— south, southeast, southwest, and east— are rendered after the center tile, so 
you have to move the unit to that new tile and set up ptUnitOffset so that it appears to remain in the 


same position. 
//set unit frame to 0 
iUnitFrame-0; 
//set the next gamestate 
iGameState=GS_DOMOVE; 
}break; 


Finally, you set the unit frame counter to 0 and set the game state to Gs_bomove. At this point, you're 
done with Gs STARTMOVE. 
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NOTE 


You don't have to have a separate game state for starting to move the unit. T hat's just 
the way | decided to do it in this case. It seems like kind of a waste, since nothing is ren- 
dered during 55 STARTMOVE, so you might want to move this code into the event handler 
or into a class or something. ГИ talk more about this later. 


GS, DOMOVE 


After the move is set up with as srARTMOVE, the next game state to be processed is GS_DOMOVE.T his game 
state is called four times and then yields control to GS_DONEMOVE. 


case GS DOMOVE: 
{ 
//move the unit offset 
switch(idMoveUnit) 
{ 
case ISO_NORTH: 
{ 
//change offset 
ptUnitOffset.x+=0; 
ptUnitOffset.y--8; 
}break; 
case ISO_NORTHEAST: 
{ 
//change offset 
ptUnitOffset.x+=8; 
ptUnitOffset.y--4; 
}break; 
case ISO_EAST: 
{ 
//change offset 
ptUnitOffset.x+=16; 
ptUnitOffset.y+=0; 
}break; 
case ISO_SOUTHEAST: 
{ 
//change offset 
ptUnitOffset.x+=8; 
ptUnitOffset.y+=4; 
}break; 
case ISO_SOUTH: 
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//change offset 
ptUnitOffset.x+=0; 
ptUnitOffset.y+=8; 
}break; 
case ISO SOUTHWEST: 
{ 


//change offset 
ptUnitOffset.x--8; 
ptUnitOffset.y+=4; 
}break; 
case ISO_WEST: 
{ 
//change offset 
ptUnitOffset.x--16; 
ptUnitOffset.y+=0; 
}break; 
case ISO NORTHWEST: 
{ 
//change offset 
ptUnitOffset.x--8; 
ptUnitOffset.y--4; 
}break; 


T he very first thing that cs_Domove does is update ptUnitoffset based on the value іп idMoveunit.T he 
values listed here come from Table 18.2, if you need to check back. 


//grab the update RECTs 

RECT rcUpdatel,rcUpdate2; 
CopyRect(&rcUpdatel,&Renderer.rcExtent); 
CopyRect(&rcUpdate2,&Renderer.rcExtent) ; 
//plot the unit's old positio 
POINT ptPlot=TilePlotter.PlotTile(ptUnitOld); 
ptPloteScroller.WorldToScreen(ptPlot); 
OffsetRect(&rcUpdatel,ptPlot.x,ptPlot.y); 
//plot the unit's new positio 
ptPlot=TilePlotter.PlotTile(ptUnit); 
ptPlot=Scroller.WorldToScreen(ptPlot) ; 
OffsetRect(&rcUpdate2,ptPlot.x,ptPlot.y); 
//merge the two update RECTS 
UnionRect(&rcUpdatel,&rcUpdatel,&rcUpdate2); 
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T his part might be a little confusing, so I’m going to spend some time on К. W hat you need to do here is 
calculate the update вғсТ5 to send to the renderer. Unfortunately, you cant just send the map location, 
because as the unit is sliding, it might be partially outside of the rectangles that bound the starting and 
ending map location (which, on the good-bad scale of things, is kind of bad). So, | chose to calculate the 
RECTS for the tile locations contained in ptunit and ptunito1d and then merge those two necrs into a 
single update rectangle, thus guaranteeing that the unit will be fully displayed. 


//scroll the frame (0,0) 
Renderer.ScrollFrame(0,0); 

//send update rect to the renderer 
Renderer.AddRect(&rcUpdatel); 
//update the frame 
Renderer.UpdateFrame(); 

//flip to show the back buffer 
lpddsMain-»Flip(O,DDFLIP WAIT); 


T hese are the standard cRenderer Calls to scroll the frame (albeit by 0 horizontally and vertically), add 
the update rectangle that you calculated earlier, update the frame, and flip the primary surface. 


//increase the unit frame counter 

iUnitFrame++; 

//check for done with gamestate 

if (iUnitFrame==4 ) 

{ 
//set to the next gamestate 
iGameState-GS DONEMOVE; 

} 

break; 


In the home stretch, | increment iUnitFrame and check to see if it equals 4 yet. W hen it reaches 4, | set 
the game state to GS_DONEMOVE. O therwise, it just continues next frame with GS_DOMOVE. 


GS DONEMOVE 
T his is the final game state. It finishes up the move, updates the map, and then returns the game to 
GS_IDLE 50 that it can wait for another keypress. 


case GS_DONEMOVE: 
{ 


//finish the move, make sure the unit is positioned correctly 
switch(idMoveUnit) 

{ 

case ISO NORTH: 
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case ISO NORTHEAST: 
case ISO NORTHWEST: 
case ISO WEST: 

{ 


//remove from old position 

mlIMap[ptUnitOld.x][ptUnitOld.y].bUnit-false; 

//place on new position 

miMapLptUnit.x][ptUnit.y].bUnit=true; 
}break; 


If you recall GS_STARTMOVE, you had a special case for а few directions— namely, north, northwest, north- 
east, and west. T his is where you correct for whatever inconsistency you might still have. It's simply a mat- 
ter of removing the unit from ptunito1d and placing it on ptunit. 


//plot new tile’s position 

POINT ptPlot=TilePlotter.PlotTile(ptUnit); 
ptPlot=Scroller.WorldToScreen(ptPlot); 
//set scrolling to 0,0 

ptScroll.x=0; 

ptScroll.y=0; 

//check for scrolling 

if(ptPlot.x«0) ptScroll.x--320; 
if(ptPlot.y«0) ptScroll.y=-240; 
if(ptPlot.x>=640) ptScroll.x-320; 
if(ptPlot.y>=480) ptScroll.y=240; 


T his should look somewhat familiar. After the move has finished, only then does the game scroll. In this 
snippet, the position of the unit is plotted, and if it is outside of the screen space, ptscro11 is set to an 
appropriate value. 


//scroll the frame 

Renderer. ScrollFrame(ptScroll.x,ptScroll.y); 
//add update tiles 

Renderer. AddTile(ptUnitOld.x,ptUnitOld.y); 
Renderer.AddTile(ptUnit.x,ptUnit.y); 


N ow the frame is scrolled (as needed) and the map locations ptunito1d and ptunit are added to the 
update list. 


//set ptUnitOffset to (0,0) 
ptUnitOffset.x-0; 
ptUnitOffset.y-0; 
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//set the old unit position to the current unit position 
ptUnitOld=ptUnit; 

//go to idling gamestate 

iGameState=GS_IDLE; 


After the tiles are sent to the update list, ptunit01d is set to the same value as ptUnit. ptUnitOffset 15 
set to (0,0), and the game state is set to GS_IDLE. 


//update the frame 

Renderer.UpdateFrame(); 

//flip 

lpddsMain-»Flip(O,DDFLIP WAIT); 
}break; 


Finally, the frame is updated by the renderer, the primary surface is flipped, and voila! A unit has success- 
fully slid from one tile to another. Seems like an awful amount of work, doesnt it? Perhaps it is. М ауре 
your game doesnt need this kind of precision as far as unit movement is concerned. It's just one of those 
things | thought I'd throw out there, just because. 


MULTIPLE OBJECTS 


T hus far, you've dealt with only a single unit of a single type all alone on a rather huge playing area. W hile 
this is useful for instructional purposes, chances are your game will have dozens of unit types and hun- 
dreds of individual units. You, as the programmer, have to find a way to keep track of all these units. 


STORAGE METHODS 


T here are many ways to keep track of units— everything from simple arrays to complex collections. 

U sually, these methods have one thing in common— they keep track of the unit in at least two places— 
once in a master list of all units (so that you can loop through the list and have them carry out orders) 
and once in the map itself. T hey may also be stored in other places, but for now, you're just concerned 
with these two. 


T he first problem you'll run into is devdoping а way to store all the units. [п simple games, you might be 
able to get away with a simple array. It's a valid technique if the game is small or has a limitation on how 
many units a player can control. M ost games, however, require something more. M y personal favorite is the 
linked list. 


If youre already familiar with linked lists and, in particular, the ST L list template, feel free to skip the next 
couple of sections. If you are unfamiliar with linked lists (or dynamic storage structures in general) or have 
never used the list template, you might want to give these sections a read, at least to get the basics. 
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дат 15 A LINKED LIST? 


A linked list is nothing more than a way to store data when you don't know how many items you will need 
to store. Consider an array for a moment. W hen you create your array, you write some code like the fol- 
lowing: 


int MyArray[10]; 


T his, as you know, sets aside enough memory to store 10 ints which, on modern computers, are 32 bits 
or 4 bytes long, so the code would set aside 40 bytes of memory which you can then access by using 
MyArray With a subscript elsewhere in code. 


Arrays are nice when you have a known number of items in a list. For example, a deck of cards can be 
contained in an array that has a size of 52, or a chessboard can be stored in an 8x8 array. H owever, 
when the number of items might at some time be stored in a list, an array just cant do it— at least, not 
efficiently. 


Following is an alternative way to declare an array of ints using С++% new operator to dynamically allo- 
cate the space on the heap: 


int ArrayElements-10; 
int* MyArray=new int[ArrayElements]; 


Using this code, you request 10 ints to be set aside on the heap, which is also known as the fre store 
meaning just a big hunk o' memory that isnt being used. T he key word in the preceding sentence is 

“requested.” T here is no guarantee that enough space for 10 ints will be available, which means that 
MyArray Will be set to 0 (NULL). Of course, this is an extreme case. M ost of the time, with modern 

machines, you have to really mess up in order to be out of memory. 


Using new to make your arrays, if you suddenly determined that you needed an extra element in the list, 
you could do something like the following: 


int* TempArray=new int[ArrayElements-*1]; 
for(int count=0;count<ArrayElements;count++) 
{ 


TempArrayLcount ]J=MyArrayLcount]; 
} 
delete[] MyArray; 
MyArray=TempArray; 
ArrayElements++; 


Looks pretty evil, doesnt it? Basically, | allocated a brand-new array, the size of the original plus 1, copied 
from one to the other, and finally deleted the old array. | know it's a mess. Also, while this method might 
be fine for small arrays of 10 or 20 elements, doing the same thing for an array that has 10,000 elements 
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дат 15 A LINKED LIST? 


A linked list is nothing more than a way to store data when you don't know how many items you will need 
to store. Consider an array for a moment. W hen you create your array, you write some code like the fol- 
lowing: 


int MyArray[10]; 


T his, as you know, sets aside enough memory to store 10 ints which, on modern computers, are 32 bits 
or 4 bytes long, so the code would set aside 40 bytes of memory which you can then access by using 
MyArray With a subscript elsewhere in code. 


Arrays are nice when you have a known number of items in a list. For example, a deck of cards can be 
contained in an array that has a size of 52, or a chessboard can be stored in an 8x8 array. H owever, 
when the number of items might at some time be stored in a list, an array just cant do it— at least, not 
efficiently. 


Following is an alternative way to declare an array of ints using С++% new operator to dynamically allo- 
cate the space on the heap: 


int ArrayElements-10; 
int* MyArray=new int[ArrayElements]; 


Using this code, you request 10 ints to be set aside on the heap, which is also known as the fre store 
meaning just a big hunk o' memory that isnt being used. T he key word in the preceding sentence is 

“requested.” T here is no guarantee that enough space for 10 ints will be available, which means that 
MyArray Will be set to 0 (NULL). Of course, this is an extreme case. M ost of the time, with modern 

machines, you have to really mess up in order to be out of memory. 


Using new to make your arrays, if you suddenly determined that you needed an extra element in the list, 
you could do something like the following: 


int* TempArray=new int[ArrayElements-*1]; 
for(int count=0;count<ArrayElements;count++) 
{ 


TempArrayLcount ]J=MyArrayLcount]; 
} 
delete[] MyArray; 
MyArray-TempArray; 
ArrayElements++; 


Looks pretty evil, doesn't it? Basically, | allocated a brand-new array, the size of the original plus 1, copied 
from one to the other, and finally deleted the old array. | know it's a mess. Also, while this method might 
be fine for small arrays of 10 or 20 elements, doing the same thing for an array that has 10,000 elements 
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is disastrous for performance. Ideally, what you would like to do is to be able to add and remove elements 
without having to do а lot of recopying. T hat is what a linked list will do, and heres why. 


How LINKED LISTS WORK 


T he basic building block of a linked list is called anode A node serves the same purpose as an index into 
an array, like МуАггауГ41. Keep in mind that "serves the same purpose" is not to be confused with 
“works the same way.” Linked lists and arrays are completely different. T he only thing they have in com- 
mon is that they both store more than one element of data. 


T hefollowing code is an example of what a typical node structure might look like: 


struct Node//basic node structure 

{ 
void* DataPtr;//pointer to the data stored in this node 
Node* next;//pointer to the next node 
Node* prev;//pointer to the previous node 

ү; 


A node consists of three simple parts. First is the DataPtr, which isnt necessarily a void*. If you need а 
linked list of integers, you would have an integer member instead— you get the idea. Т he other two parts 
are integral to the way linked lists work. In order to arbitrarily insert nodes, you keep track of the next 
node in the list (with the next member), and you also keep track of the node just prior to the current one 
(with the prev members). H ence, the nodes are linked into alittle string of pointers, so they are called 
linked lists. Н aving both a next and prev pointer means that it is а “doubly linked list” since you can navi- 
gate both ways along the list of nodes. 


HEADS OR TAILS 


In your linked list, two nodes are special: the head node and the tail node You might call then “front and 
back” or “top and bottom” or “first and last,” but suffice it to say that the list “starts” at the head node 
and “ends” at the tail node, even though you can work backwards from the tail node and wind up back at 
the head node T his is just the convention used. If you want to use other terminology that you feel more 
comfortable with, you're free to do so. 


Figure 18.9 shows how a linked list works. It shows identical rows of nodes, including the head node and 

tail node T he top row shows how the next pointers are assigned to the address of the next node, and the 
bottom row shows a similar thing for the prev pointers. (Showing them both at the same time would be a 
mess of crisscrossed lines that would be hard to read.) 
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Figure 18.9 


Visual representation 
of a linked list 


ROLLING YOUR OWN LINKED LIST 


Even though I'm going to get to the ST L list template іп a few moments, no discussion about linked lists 
is complete without at least showing how to make one on your own. Several methods are used to make 
linked lists. Some use the same node for head and tail, in reality making a sort of “linked ring" For our 
purposes, | will have the head and tail nodes as separate nodes, both of which will contain nothing except 
links to other nodes, so at any given time, our linked list will contain at least two nodes. 


ode* pHead;//head node 

ode* pTail;//tail node 

//allocate the head and tail nodes 

pHead=new Node; 

pTail=new Node; 

//point the head and tail nodes to one another and to NULL 
pHead-»prevzNULL; 

pHead->next=pTail; 

pTail->prev=pHead; 

pTail->next=NULL; 


T his code snippet sets up the head and tail for a linked list. It is important to note that all nodes must be 
dynamically allocated (by using either new ОГ malloc). You cannot take а local variable of type Node and 
add it to the list, because that variable disappears as soon as the function returns, which means that your 
linked list will be broken. It is perfectly fine to use new ОГ malloc to create new nodes within functions 
using local Node* variables. 
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ADDING TO THE LINKED LIST 

Just having a head and tail node (both of which contain nothing) won't get you anywhere. In order for the 
list to be useful, you must populate it with data, which means you have to insert nodes. T he first insertion 
I'm going to show you is how to insert a node at the beginning of the list (right after the node pointed to 
by pHead). 


Node* pNode-new Node;//allocate a new node 

//set up the data in the node here 

pNode->next=pHead->next;//copy the next pointer from pHead 
pNode->prev=pHead;//set the prev pointer to the top of the list (pHead) 
pHead->next=pNode;//point to the new node from pHead 


As you can see, theres a whole lot of messing around with the next and prev pointers. T his is the basis 
for how linked lists work and is also the source of most of the errors associated with linked lists. 


N ext, I’m going to show you how to add anode to the end (right before рта11).Т his code is rather simi- 
lar to the previous "top of list" code. It just switches next for prev. 


Node* pNode-new Node; 

//set up data in node here 

pNode->prev=pTail->prev;//copy prev pointer from tail to new node 
pNode->next=pTail;//point to tail from new node 
plail->prev=pNode;//point to new node from tail 


Likel said, №5 about the same code either way. M ost of the time, these two insertions are the only ones 
you'll use. Н owever, fast arbitrary insertions are one of the strengths of linked lists, and the code is almost 
identical to the code I've already shown, so let's take a look. 


In both of the following examples, pcurrent is a node somewhere in the list, and not the head or the tail. 
First, here is how to insert a node after pcurrent: 


Node* pNode-new Node;//allocate new node 

//set up data within node here 
pNode->next=pCurrent->next;//set new node's next pointer 
pNode->prev=pCurrent;//set new node's prev pointer 
pCurrent->next=pNode;//update pCurrent's next pointer 


If you're saying “Н ey!You can take the ‘insert after the head’ code and replace all the pHeads with 
pCurrentsl” you are correct, and you get a blue ribbon. In fact, to do the “insert before pcurrent” code, 
you can just take the “insert before tail” code and replace рТа11 with pCurrent. It's just that easy. 


OBJECT PLACEMENT AND MOVEMENT 


DELETING FROM A LINKED LIST 


In order to delete a node from a linked list, the list must first have a node that is not the head or the tail. 
D deting the head or tail nodes can be disastrous for this style of linked list. For this example, we return to 
Using pCurrent as a node somewhere in the list that is neither the head nor the tail. 


ode* pNextNode=pCurrent->next;//get a pointer to the next node 
ode* pPrevNode=pCurrent->prev;//get a pointer to the previous node 
pNextNode->prev=pPrevNode;//link next node to previous node 
pPrevNode->next=pNextNode;//link previous node to next node 

//do whatever needs doing to free up the data used by the node here 
delete pCurrent;//delete the current node 

pCurrent=pNextNode;//set pCurrent to a valid node 


CHECKING FOR HN EMPTY LIST 

Quite commonly, you will need to check if the list has any node (not the head or tail) in it. W ith this style 
of linked list, this is a pretty easy check. You can do it two ways. О ne, you can see if the next pointer of 
pHead points to рта11: 


if (pHead->next==pTail) {/*the list is empty*/] 
And two, you can seeif the prev pointer of рта11 points to pHead: 
if(pTail->prev==pHead){/*the list is empty*/} 


It is not always necessary to check if a list is empty before iterating through it, but this is a good idea at 
many other times. 


ITERATING THROUGH A LIST 


T he word “iterate” might be new to you, even though you are already familiar with the concept. W henever 
you do a for loop, you are in fact iterating: 


for(int count=0;count<MAXVALUE;count++) 
{ 
//do something 


In this piece of code, you “iterate” through a number of values for count, which might be used as ап 
index into an array or part of a function that totals the values of count, searches for a particular item, or 
whatever. 


T he dictionary definition of iteration is "the process of repeating a set of instructions а specified number 
of times or until a specific result is achieved.” T his is straight out of the American H eritage D ictionary of the 
Endish Language T hird Edition. W hat better way to describe a for loop?A simpler definition is that iteration 
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involves repetitive tasks, such as looking at each of the values stored in an array. In a linked list, you iterate 
through all the nodes in the list, usually performing some action with them. 


In order to iterate, you must first have an iterator. In the preceding for loop, the variable count was the 
iterator. W ith your linked lists, you will use a node to step your way through the list. 


NOTE 
Another good example of an iterator is how the CTi 1eWalker class is used by 


CMouseMap to determine the position of a pixel on-screen. 


Generally speaking, you will want to iterate through a linked list one of two ways: either forward or back- 
ward, and usually from head to tail or tail to head. Both methods are very similar. Н егес a little look-see at 
iterating from head to tail: 


Node* pCurrent=pHead->next;//pHead is NOT the first node in the list; pHead->next 
15 
while(pCurrent!=pTail)//while pCurrent does not point to the tail of the list 
{ 
//do something with the current node 
pCurrent=pCurrent->next;//move to the next node in the list 
} 


Or, if you prefer to use for rather than white (I know | do, anyway), do this: 


for(pCurrent=pHead->next;pCurrent!=pTail;pCurrent=pCurrent->next) 
{ 

//do something with the current node 
} 


During a list iteration, you might perform one of a number of operations, like counting nodes, searching 
for a particular node, modifying the data stored in the node, and so on. Be careful about deleting or 
adding nodes, however. If you add a node as a result of an iteration, you might not want it to be part of 
the current iteration, in which case you probably want to add it to the beginning of the list. H owever, you 
might indeed want to have the new item be part of this iteration, in which case you would add it to the 
end. It's all a matter of what function the iteration performs. Just be sure you design your iterations prop- 
erly, and everything should be fine. 


If you want to loop from tail to head, you just reverse everything, like so: 


for(pCurrent=pTail->prev;pCurrent!=pHead;pCurrent=pCurrent->prev) 
{ 
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//do something with pCurrent here 


One of the more common tasks you will use list iteration for is that of searching out a particular node. 
Т he way | normally go about this 15 shown next. For the moment, assume that Node contains а menber 
called Value that isan int, and assume that | am looking for the number 13 in the list. 


Node* pFound=NULL;//this node will point to a node, if found, 
//and NULL if not found 
for(pCurrent=pHead->next;pCurrent!=pTail;pCurrent=pCurrent->next) 
{ 


if (pCurrent->Value==13)//check for a value of 13 

{ 

pFound=pCurrent;//set the found node to the current node 
break;//break out of the loop 


} 
if (pFound) 
{ 
//found a node! 


//did not find a node! 


At this point, |'m going to point out a major weakness of linked lists. W henever you want to do anything, 
like search, count, or whatever, you have to go from one end to the other, one step at a time. T his makes 
accessing a given node (for example, the fifth node) slower than it is in an array. H owever, most of the 
time you will use linked lists in places where moving from one end to the other is what you wanted to do 
in the first place anyway, so this is not a problem. Plus, you gain the ability to arbitrarily insert and delete 
items quickly, which is not possiblein an array. 


Another common iteration you will be likely to perform is that of counting nodes. Т his is a rather simple 
matter. 


int Tally=0;//initialize counter to 0 
for(pCurrent=pHead->next;pCurrent!=pTail;pCurrent=pCurrent->next) //iterate 
Tally++;//for each node, add one to Tally 


N o big deal, right? Н ow tough can counting things be, really? U nfortunately, counting the nodes does 
require moving through the entire list each time you want to do so, and since adding nodes is so easy (it 
can be done anywhere in code), keeping track of a count separately can be a pain. 
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Fortunately, many times you dont really саге how many items are in a list. In а strategy game, for example, 
you might be concerned with only three values: 0, 1, and more than 1. If a given map location has no 
units, dont render anything. If the map location has one unit, render it. If the map location has two 

or more units, you want to render whatever unit is “on top” of the stack (the first node in the list), 

and you want to render some sort of visual clue to let the player know that there is a stack of units on 
this location. 


| have already shown you how to check if alist has zero nodes— just check to see if it is empty or not. In 
order to check for a single unit in the list, you just compare pHead->next and pTail->prev. If these two 
values are the same the list contains exactly one unit. In any other case there is "more than one" unit. 


THE STL іл-т TEMPLATE 


N ow that I've gone over how to create and implement a linked list, let's switch gears and just use Standard 
Template Library (ST L). STL isalibrary of templates that comes with most if not all C++ compilers, 
including Visual C++ (hence the S іп ST L). 


If you arent familiar with templates, they are a way to make a generic function or class that applies to 
many different types without having to rewrite the code. For example, with a linked list, you have no idea 
what kind of data you want to store in it, and using void is just kind of messy. T he declaration for 

ST L5 list looks like the following: 


template<class T,class A=allocator<T>> class list{/*...*/} 


T he values between the < and the > are similar to function parameters that lie between a (and a), except 
that now, the parameters are types. In alist, class T represents what you want to store in the list. It can 
ре any type— int, void*, float, double, or a struct or class that you make yourself. class А represents an 
allocator for an object of class т, but you dont worry about that, since it defaults to all ocator<T>, 
which is a generic version of an allocator object. 


In order to use ST L's list template, you only have to do the following: 


jdinclude <list>//include the header file 
std::list<int> MyList;//declare a linked list of ints 
//now we can use MyList 


If the std part confuses you, it is because the list template resides in a namespace called sta (meaning 
“standard,” of course). A namespace is simply a mechanism to keep name clashes to a minimum. T he word 
“list” is rather common, especially in programming. 


M ost of the time, you will use the ST L list by first defining a struct or class that will store the informa- 
tion for something. T hen you will make a list for that class or struct. (Personally, | like to турде them 
into more easily readable type aliases.) 
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struct UnitInfo{/*...*/};//unit information structure 

typedef UnitInfo *PUNITINFO;//point typedef for unit info struct 

typedef std::list<PUNITINFO> UNITLIST;//typedef for unit list 

typedef std::list<PUNITINFO>::iterator UNITLISTITER;//typedef for unit list iter- 
ator 


After this code, you can just use UNITLIST instead of std::1ist<PUNITINFO> to declare your list and 
work with that list type Ah, the power of typedef to keep us from hurting ourselves!T he last line 
declares a type alias for the iterator type contained in the list template (the iterator is also a template). 
Well use this iterator to walk through the list later. | just wanted to show you how to declare one 


I’m not going to show you the ins and outs of the list template. О ne, it would take too long, and two, it 
would be a waste of space, since our use of lists is mainly just to keep track of units. М ainly, l'II just show 
you how to add, remove, and count items, check for emptiness, and iterate through a list. 


For all of these examples, you will assume that the code using Unit Info and РИМІТІМЕО is what you're 
doing, plus the following declaration: 


UNITLIST MainUnitList;//declare the main unit list 


TippiNG ITEMS 


Just as when you rolled your own, there are three different ways you might liketo add a new item to the 
list: at the beginning, at the end, or somewhere in the middle To add an item to the beginning of the list 
(STL calls this the "front" of the list), you use push. front, like so: 


PUNITINFO pUnitInfo=new UnitInfo;//allocate a new unit 
//set up pUnitInfo here 
MainUnitList.push_front(pUnitInfo);//put it in at the beginning 


If instead you would like to place a new item at the end of the list, you use push_back: 


PUNITINFO pUnitInfo=new UnitInfo;//allocate a new unit 
//set up pUnitInfo here 
MainUnitList.push_back(pUnitInfo);//put it in at the beginning 


T he third method, arbitrary insertion, requires an iterator (in this case, a UNITLISTITER), and you use 
the insert method. T he iterator works kind of like pcurrent did in the “Rolling Your O wn Linked List” 
section. 


//assume iter is a valid UNITLISTITER 

PUNITINFO pUnitInfo=new UnitInfo;//allocate a new unit 

//set up pUnitInfo here 

MainUnitList.insert(iter,pUnitInfo);//iter is a valid iterator for this list 
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Га like to point out that in all cases, the insert method places the new item before (in the direction of 
the beginning of the list from) the iterator, not after. T here are two other overloaded insert methods, but 
l'm not going to cover then. We can make do with this "single item" insertion. 


REMOVING ITEMS 


To remove items, you use the remove method of the list template If your list is using pointers to a struct, 
you probably first want to iterate through a list to find out what pointer you want to get rid of, and then 


USe remove: 


//assume pUnitInfo is a pointer that you want removed from the list 
MainUnitList.remove(pUnitInfo);//removes all items that equal pUnitInfo 


If you instead have an iterator at which you would like the removal to occur, you can use erase instead: 


/lassume iter is a valid iterator 
iter=MainUnitList.erase(iter);//remove the item at the iterator, points the 
iterator to the item after 


And, just in case you are interested in removing all the items in the list, | present the clear method: 


//clear out the list 
MainUnitList.clear(); 


If you are dynamically allocating items before placing them in the list, you probably want to iterate 
through and deallocate all the items in the list prior to using clear, or else you'll have а memory leak. If 
you want to remove items at the beginning or end of the list, you can use pop_front and pop_back. 

N either has any parameters. 


CHECKING FOR EMPTINESS 
T his one is really easy. To do this, you use the empty method: 


if(MainUnitList.empty()) 
{ 
//empty 


//not empty 


Likel said... not a difficult method to master. 
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COUNTING ITEMS 
Also not a very complicated method for ST L lists. T his time, the word is size. 


int ItemCount=MainUnitList.size();//get the number of items in the list 


W hile the documentation doesnt say this, you know full well that when size is called, it iterates through 
the entire list. You might not want that to happen. You might only be concerned about whether a list has 
zero, one, or two items. l'Il get to how to do that with an ST L list in just a moment. 


ITERATING THROUGH A LIST 


T he final piece of using the ST L list is iteration. R ather than going into explanations of the special itera- 
tors that are built into the list class, let me just show you the generic iteration loop, and then I'll explain it 
in terms of the “roll your own” example. 


PUNITINFO pUnitInfo=NULL; 
for(UNITLISTITER iter=MainUnitList.begin();iter!=MainUnitList.end();iter++) 
{ 

pUnitInfo=*iter;//grab the unit pointer from the iterator 

//do something with pUnitInfo 


MainUnitList.begin() Works in a manner similar to pHead->next. It is the first item in the list if you 
are iterating forward. MainUnitList.end() Is similar to pTail. iter++ uses an overloaded operator (++) 
to move to the next node in the list. Another overloaded operator (ғ) is used by the iterator to access the 
data stored there. | ve used the preceding code as a basis for my list iterations since | started using them. It 
hasn't failed me yet. It wont fail you either. 


As promised, I’m going to show you a quick function to check for how large a stack of items is using ST L 
and not iterating through the entire list using size. 


int StackSize(UNITLIST& UnitList) 
{ 


if(UnitList.empty()) return(0);//check for empty 

UNITLISTITER iter-UnitList.begin();//move to beginning of list 

iter++;//move to the next item (we know there is at least one) 

if(iter==UnitList.end()) return(1);//if we are at the end of the list, 
//there is only one unit in the stack 

return(2);//all other cases, there are at least two units 


T his way is a lot more efficient than iterating through the entire list each time you want to see how large a 
stack of units is, which is a very common task. Got all that?T he ST L lists will be a lot easier once you've 
worked with them. 
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MULTIPLE UNITS 


N ow that you've got a handle on linked lists, you can make examples that start to actually resemble 
strategy games. T he first example in this vein is SoH ех18 3.срр. Before! actually get into how it was 
built, however, I'd like to take а moment to talk about the general idea of a turn-based strategy game, and 
how the program will flow (in other words. . . design). 


In turn-based strategy games, two or more players fight against each other, the goal being to ether eimi- 
nate all the other players or achieve some victory condition known from the start of the game T he players 
might be actual human beings playing in turn on the same machine (this is called "hot seat multiplayer"), 
human beings playing over a network or the Internet, or computer-controlled players. 


Regardless of who is playing (human or computer), the game takes place in turns. Each player gets a 
chance to give all his units (and/ or bases) orders. In some games, the action is resolved automatically dur- 
ing the player's turn. In other games, the action is resolved only after all players have given their units 
orders. M ost of the time, the “immediate resolution" mode is used, unless there is some overwhelming 
reason not to. D uring a player's turn, he may order any or all of his units to move, attack, or perform some 
special action, or just do nothing. Special actions vary from game to game, but they typically include forti- 
fying ones position, “sleeping” until an enemy unit comes into range, boarding a naval vessel, destroying 
structures (farms, roads, mines) built by enemy players, performing spy functions, or just about anything 
dse you can imagine. 


IsoH ех18 3.cpp doesnt concern itself with any of the special actions. R ather, it just allows a team of 
units to be moved around a tilemap. H owever, this example is a good step toward implementing an honest- 
to-goodness turn-based strategy game. 
Н егес a basic rundown of а gameturn. A "game turn" is different from a "player turn" in that each player 
has his player turn before a single game turn elapses. 

GameTurn #1: 

Player #1 gives his units orders (orders are carried out immediately) 

Player #2 gives his units orders (orders are carried out immediately) 


GameTurn £2: 
Player #1 gives his units orders (orders are carried out immediately) 
Player #2 gives his units orders (orders are carried out immediately) 


(and so on) 


With each player turn, typically the following actions occur: 
Player Turn: 
Check to see if player has achieved “victory condition.” 
Do whatever “upkeep” is necessary. (T here might be maintenance costs for units.) 


For each unit: 
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Wait for a command from the player. 
Carry out the command. 


N ow that you've got the basic flow down, keep it in mind as | discuss the code. T here are a number of dif- 
ferences between ISoH ех18 3 and prior examples. For one thing, most of Prog Loop has been completely 
rewritten and the map structure completely changed. | took out thetree (I knew you were getting tired of 
seeing it; it's rather homely), and | added a new type of unit. M ost fundamentally, you are now using 
linked lists to store your units. 


CONSTANTS AND GLOSALS 


№ aturally, the constants and globals changed quite а bit. First, | made the map smaller (theres no need to 
have a huge map for a simple unit example). It is now 40x40 tiles, so at least it's bigger than the screen. | 
could have had as large a map as | wanted. 


con 
con 
//9 
con 
con 
con 
con 
con 
con 
con 
con 
con 


© 
S 
a 
5 
© 
5 
5 
5 
5 
5 
5 
© 


5 D ud. а um m= Ser Se c3 
с 


а 


t MAPW 
t MAPH 


tes 
GS T 
GS S 
GS E 


GS NE 


GS 5 


IDTH-40; 
EIGHT-40; 


DLE=0;//waits for a keypress 


RTTURN=1;//starts a player's turn 


TUNIT=3;//finds the next unit to move 


Е 
А 
DTURN=2;//ends а player’s turn 
X 
A 


RTMOVE=4;//starts moving the unit 


GS_DOMOVE=5;//moves the unit 


GS_E 
GS_N 
GS_S 


DMOVE=6;//ends a unit move 
ULLMOVE=7;//tells a unit to not move 
IPMOVE=8;//temporarily skips the move 


T he second big change to the constants are the game states. T he last example had only four. N ow, there are 
nine. Table 18.4 lists these game states and their purposes. 
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Table 18.4 IsoHex18 З Game States 
Game State Purpose 


GS IDLE This game state is "neutral" and is used to wait for keyboard input 
from the player 

GS STARTTURN At the beginning of a player's turn, this game state takes care of 
all details that need to be taken care of at that time 

GS ENDTURN At the end of a player's turn, this game state cleans up whatever 
needs cleaning and sets the next player as the new current player 

GS NEXTUNIT This game state selects the next unit to receive commands from 
the current player 

GS STARTMOVE After a move command has been received from the player, 
GS STARTMOVE begins the move 

GS DOMOVE After a move has begun, GS_DOMOVE implements the actual move 

GS ENDMOVE This game state finalizes a unit's movement 

05 NULLMOVE If the player chooses not to move a unit during his turn, GS. NULLMOVE 


takes care of it 


GS SKIPMOVE If the player does not want to move the current unit, but would 
like the option to move it this turn, he can skip this unit and 
come back to it later 


Figure 18.10 shows a graphical view of these game states as well as the basic flow from game state to game 
state. From this figure, it is easy to see that cs МЕХТИМІТ and GS_IDLE are the most important. M ost of 
the time, the game will bein as тоге, waiting for keyboard input. 
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Figure 18.10 


Unit Queue Not Empty GS IDLE Graphical view of 
game states 


Well talk all about these game states a little later. For now, let's get back to globals. 


struct UnitInfo//unit information structure 
{ 


int iType;//type of unit 
int iTeam;//team to which the unit belongs 
POINT ptPosition;//map location of the unit 


bs 
typedef UnitInfo *PUNITINFO;//pointer type alias for unitinfo 

typedef std::list<PUNITINFO> UNITLIST;//list of units 

typedef std::list<PUNITINFO>::iterator UNITLISTITER;//iterator for unit list 


| sort of covered this earlier, in the discussion of linked lists. | defined a Unit Info structure to contain 
all the pertinent information about an individual unit. Table 18.5 lists the members of Unit Info and 
their meanings. 
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Table 18.5 Unitinfo Members 
Member Meaning 


iType The type of the unit. In tsUnit, there are two images, each of 
which represents a "type" of unit. 


iTeam The team or player to whom this unit belongs.A new tileset 

called tsShield has images of shields with differing colors to 
represent the different teams. Currently there are two teams: 
blue(0) and red(1). 


ptPosition The map location in which this unit can be found. 


Besides Unitinfo's definition, a number of typedefs are used for the linked lists. PUNITINFO is a pointer 
type alias for Unit Info. UNITLIST is an ST L list that keeps PUNITINFOS. UNITLISTITER 15 an iterator for 
UNITLIST. 


//map location structure 
struct MapLocation 
{ 
UNITLIST ulUnitList;//list of units on this map location 
Із 
MapLocation mlMap[LMAPWIDTH]LMAPHEIGHT];//map array 


T he MapLocation Structure has been completely changed as well. Both bTree and bunit have been taken 
out, and they have been replaced by а UNITLIST. Each map location maintains a list of all the units cur- 
rently occupying that location. 


UNITLIST MainUnitList;//unit list for all units 

UNITLIST TeamUnitList;//unit list for teams (current player’s turn) 
PUNITINFO pCurrentUnit;//current unit being moved 

bool bFlash;//controls the flashing of the current unit 

ISODIRECTION idMoveUnit;//direction in which the unit will be moved 


T his stuff is used to manage the units. MainUnitList Is, to no ones surprise, a master list of all units in 
the game. 


TeamUnitList is а list containing all the current player's units. It gets filled during cs. srARTMOVE and is 
slowly emptied from Gs NEXTUNIT. pCurrentUnit represents the current unit, or the unit that the player 
is going to give orders to. It is assigned during GS_NEXTUNIT. bF1ash toggles between false and true during 
05 IDLE. If it's false the current unit will not be shown during the current frame. If it's true, the current 
unit will be shown during the current frame T his results in a nice effect of a "blinking unit" to give the 
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player a visual clue that this is the unit he will be moving. iaMoveunit is the same as it was in prior exam- 
ples. It controls a unit's direction of movement. 


T here are a few more globals, like icurrentTeam, which keeps track of which player is having his turn. 
Also, there is an additional tileset variable cssnie1a, which 1711 get into more detail about in this examples 
rendering function. 


MAIN LOOP 


N ow that all the preliminaries are out of the way, we can get to the meat of the program— namely, the 
game states that Prog Loop responds to. Т hese are in no particular order, so if you have to refer to 
Figure 18.10 or Table 18.4 to keep them straight in your head, that’s OK. 


GSo_STARTTURN 


Start at the beginning, and when you come to the end, stop. T hat's good advice, and I'm going to follow it here T he 
following snippet handles cs srARTTURN, which occurs at the beginning of a player's turn. 


case GS STARTTURN://start the current team's turn 
{ 
PUNITINFO pUnitInfo;//variable to check for the team’s units 
UNITLISTITER iter;//iterator for the main unit list 
for(iter=MainUnitList.begin();iter!=MainUnitList.end();iter++) 
//iterate through the main unit list 


pUnitInfo-*iter;//grab the unit from the list 
if(pUnitInfo-»iTeam--iCurrentTeam) 

//does this unit belong to the current team? 
{ 


//add this unit to the team list 
TeamUnitList.push back(pUnitInfo); 


} 

//set the next gamestate 

iGameState=GS_NEXTUNIT; 
}break; 


T his game state doesnt do much, but what it does is very important. Basically, at the start of the player's 
turn, all his units (or, at least, pointers to them) are taken from MainUnitList and are added to 
TeamUnitList.T he main work is done by an iteration loop, which is a "search" loop that checks to see if 
the i Team member of Unit Info is the same as iCurrentTeam. If this criteria is met, the unit is added to 
the team’s unit list. After the TeamUnitList has been filled, this game state yields to the next game state, 
GS NEXTUNIT. 
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Go NEXTUNIT 


Other than as_1DLe, the program spends the most time in GS_NEXTUNIT, which is perhaps the most 
important game state in the entire program. T his опе is a big one, so | will "annotate" as | go along. 


case GS_NEXTUNIT://select the next unit as the current unit 
{ 


//set current unit to NULL 
pCurrentUnit=NULL; 
if(TeamUnitList.empty())//if the team unit list is empty 
{ 
iGameState-GS ENDTURN;//end the turn 


Т he entire purpose of GS_NEXTUNIT is to set the current unit (pCurrentunit) to point to whatever the 
next unit owned by the current player (icurrentTeam) is to move. Since all the player's units were placed 
ІП TeamUnitList during GS_STARTTURN, the task is somewhat simplified. First, you check to see if 
TeamUnitList is empty. If it is, this player's turn is over, and you yield control to Gs. ENDTURN. 


else 
{ 


//turn is not over 
UNITLISTITER iter=TeamUnitList.begin(); 

//get the first unit in the team list 
pCurrentUnit=*iter;//grab the unit from the list 
TeamUnitList.pop_front();//remove the unit from the list 


If TeamUnitList is not empty, simply take the unit from the top or front of the list (by setting an itera- 
tor to the beginning of the list and grabbing the unit pointer from there). After you have this value, 
remove this unit from TeamUnitList, since presumably the unit will be moved. If it is not moved, you will 
replace it in the list. 


mlMapLpCurrentUnit->ptPosition.x] 
[pCurrentUnit-»ptPosition.y].ulUnitList.remove( 
pCurrentUnit); 
//remove the unit from the map location 
mlMap[pCurrentUnit-»ptPosition.x] 
[pCurrentUnit-»ptPosition.y].ulUnitList.push front( 
pCurrentUnit);//place unit at the top of the 

//map locations unit list 


T his part might puzzle you, because the reasons for doing it are not entirely self-evident. | discovered a 
need to do this while writing the example T he rendering function only renders the image of the unit that 
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is at the top or front of the map location's unit list, which means that if you want the current unit to be 
seen, it must be at the beginning of the list. T hat's what the preceding lines of code do. T he first line 
removes the unit from the list, and the second line puts it in the front of the list. 


POINT ptPlot=TilePlotter.PlotTile(pCurrentUnit->ptPosition) ; 
//plot the unit’s location 
POINT ptScreen=Scroller.WorldToScreen(ptPlot); 

//translate into screen coordinates 
if(!}PtInRect(Scroller.GetScreenSpace(),ptScreen) ) 
//check to see if point is within screenspace 
{ 


//not on screen 
ptPlot.x-=(Scroller.GetScreenSpaceWidth()/2); 
ptPlot.y-=(Scroller.GetAnchorSpaceHeight()/2); 
//set the anchor 
Scroller.SetAnchor(&ptPlot); 

Renderer.AddRect(Scroller.GetScreenSpace()); 


} 
iGameState-GS IDLE;//set to idling gamestate 
} 
}break; 


Before yielding to Gs_IDLE (the final task that takes place in GS_NEXTUNIT), you first must guarantee that 
the unit can be seen on-screen. | took a rather simple approach to this by plotting the tile, translating to 
screen coordinates, and checking to see if this point is within the screen space. If it isnt, the scroller's 
anchor is modified to center on the unit, and the renderer is told to update the entire screen. T his method 
works, but it's less than ideal, especially when a unit is near the edge of the screen space. You might replace 
the screen space rectangle with some other rectangle that guarantees that the entire unit will be visible on- 
screen, 


аш ENDTUNMSN 


As | said earlier, these game states are in no particular order. (Actually, they are, but explaining how my 
mind works would take a whole other book.) T he next on the list is 05 ENDTURN. 


case GS ENDTURN://end of a player's turn 
{ 


//clear out team unit list (just to be sure) 

TeamUnitList.clear(); 

//change team 

iCurrentTeam=1-iCurrentTeam; 

iGameState=GS_STARTTURN;//set gamestate to start next turn 
}break; 
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T his one is pretty short and sweet. First, you clear out the TeamUnitList. It's empty already, of course, 
because otherwise, GS_NEXTUNIT would not have sent you to cs. ENDTURN, but clearing out an empty list 
doesnt take up any overhead (at least, not enough to worry about), and being safe is good. After you have 
ensured that the TeamUnitList is empty, the next player is selected (by changing the value of 
iCurrentTeam), and you are then sent to Gs. STARTTURN to start the cycle over. 


а- IDLE 


As stated earlier, most of the time spent in the program is spent in сѕ_ тоге. Its job is to update the dis- 
play each frame until keyboard input is processed, at which time you switch to another game state. 


case GS IDLE://the game is idling; update the frame, but that's about it. 
{ 
DWORD dwlimeStart=GetTickCount();//get the frame start time 
//scroll the frame (0,0) 
Renderer.ScrollFrame(0,0); 
//toggle unit flash 
bFlash=!bFlash; 
//add the tile in which the current unit lives 
Renderer.AddTile(pCurrentUnit->ptPosition.x,pCurrentUnit- 
>ptPosition.y); 
//update the frame 
Renderer.UpdateFrame(); 
//flip to show the back buffer 
lpddsMain-»Flip(O,DDFLIP WAIT); 
//wait until 200 ms have passed 
while(GetTickCount()-dwTimeStart«200); 
break; 


T here is nothing earth-shattering here. M ainly, you just tell the renderer to do its job. T heres one thing of 
note, however. Your new global, bF1asn, changes value each time es_1DLE is executed, and the tile occu- 
pied by the current unit is updated. Also, a frame limiter ensures that 200 milliseconds pass before another 
frame is shown. T his is what gives you a “flashing unit" effect for whichever unit is the current unit 
(pCurrentUnit).T here will be more about this when | cover the rendering function. 


GS_NULLMOVE 
T his game state is one of three ways to get out of as_1DLe.To get here, the user presses the spacebar, 
indicating that he does not want to move this unit this turn. 


case GS_NULLMOVE://do not move the current unit 
{ 
//don’t really do anything, just go to the next unit 
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pCurrentUnit=NULL; 
iGameState=GS_NEXTUNIT; 
}break; 


N ot alot going on here. You set the current unit to NULL and set the game state to GS_NEXTUNIT. 


GS_SRIPMOVE 


T he second option for getting out of 65 тоге is GS_SKIPMOVE. You can get there by pressing theW key 
on the keyboard, indicating that you might still want to move this unit a little later, but not right now. 


case GS SKIPMOVE://skip this unit for now 
{ 
//put unit at end of team unit list 
TeamUnitList.push back(pCurrentUnit); 
pCurrentUnit=NULL;//set current unit to NULL 
iGameState=GS_NEXTUNIT;//select the next unit 
}break; 


T his game state is only slightly more complicated than Gs_NULLMoveE. In fact, it adds only one line Since 
the player might want to move the unit later, you replace it back in TeamUnitList before setting the cur- 
rent unit to NULL and moving to GS_NEXTUNIT. 


GS_STARTMOVE 


T his is the third and final way to get out of 65 тоге. It is accomplished by processing a movement key- 
stroke. T he movement keys are the arrow keys, the numeric keypad, and Н ome, End, Page U p, and Page 
Down. (T he numeric keypad works whether N um L ock is on or off.) 


case GS STARTMOVE: 
{ 


//remove the unit from the map location 
mlMapLpCurrentUnit->ptPosition.x] 
[pCurrentUnit-»ptPosition.y].ulUnitList.remove( 
pCurrentUnit); 
Renderer.AddTile(pCurrentUnit-»ptPosition.x,pCurrentUnit- 
»ptPosition.y); 
//set next gamestate 
iGameState-GS DOMOVE; 
}break; 


T his example, as you might have already noticed, does not use the methods | discussed іп IsoH ex18 2, 
where you smoothly slid the unit from one tile to another. Н owever, all the appropriate game states already 
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exist in this example, so implementing it wouldnt be that big of a deal. T he reason that | did not is 
because | wanted to showcase the linked list and multiple-unit stuff without cluttering it up with other 
code. 


In GS_STARTMOVE, the current unit is removed from its current map location, and that map location's coor- 
dinates are added to the renderer for updating. N o rendering is done during cs. srARTMOVE. N ext, the 
game moves to aS_DOMOVE. In essence, GS_STARTMOVE is "picking up" the unit, much in the same way you 
would pick up a chess piece. 


Go DONYOVE 


T his game state performs the actual move. If Gs srARTMOVE is picking up the piece, this game state is 
actually moving it (but not setting it down). 


case GS DOMOVE: 

{ 
//move the unit 
pCurrentUnit->ptPosition= 

TileWalker.TileWalk(pCurrentUnit->ptPosition,idMoveUnit) ; 

//set next gamestate 
iGameState=GS_ENDMOVE ; 

}break; 


T his is an easy one Simply use theT ileW alker to move the current unit's ptPosition member, and then 
send the game into GS_ENDMOVE. 


NOTE 
It might seem silly to have these very small, overly broken-up game states, but | feel that 


they illustrate the concept pretty well in bite-sized pieces, rather than dumping a whole 
bunch of code on you and then saying “Here, figure this out.” In reality, you would prob- 
ably implement it differently, but the same things would still occur. 


Go ENDIYOVE 


T his is the last game state, where you finally "set the piece down.’ After this game state, a unit is consid- 
ered to have made a complete move, and then the next unit is selected. 


case GS_ENDMOVE: 
{ 
//place the unit on its new map location 
mlMapLpCurrentUnit->ptPosition.x] 
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[pCurrentUnit- 

»ptPosition.y].ulUnitList.push front(pCurrentUnit); 

Renderer.AddTile(pCurrentUnit-»ptPosition.x,pCurrentUnit- 
>ptPosition.y); 

pCurrentUnit=NULL; 

//set next gamestate 
iGameState=GS_NEXTUNIT; 

a 

r 


DWORD dwlimeStart=GetTickCount();//get the frame start time 
//scroll the frame (0,0) 
Renderer.ScrollFrame(0,0); 
//update the frame 
Renderer.UpdateFrame(); 
//flip to show the back buffer 
lpddsMain-»Flip(O,DDFLIP WAIT); 
//wait until 500 ms have passed 
while(GetTickCount()-dwTimeStart«500); 

}break; 


zi 


T his game state does sort of the opposite of Gs srARTMOvE by placing the unit onto its new position. 

T hen, a single frame is rendered, and the game waits for 500 milliseconds so that you get at least a half- 
second to see where your unit has moved. After that, the game moves to GS_NEXTUNIT, where the process 
starts all over again. 


N ext, | want to move on to the rendering function, which will bring to light certain details that | have yet 
to discuss. 


RENDERING FUNCTION 


Ah, the rendering function. .. workhorse of the renderer, which accomplishes all the drawing for the entire 
application. T his time around, the rendering function has changed a great deal, and it has gotten rather 
large, so I'm going to discuss it bit by bit. 


void RenderFunc(LPDIRECTDRAWSURFACE7 1раа505%, RECT* rcClip, int xDst, int yDst, 
int xMap, int yMap) 
{ 

//put background tile 

tsBack.ClipTile(lpddsDst,rcClip,xDst,yDst,0); 


T his part you've seen before. It's the only part that didnt change from prior examples. N aturally, you have 
to render the background tile before rendering anything else. 


//check for an empty list 
if(!mIMap[xMap]LyMap].ulUnitList.empty()) 
{ 
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T he remainder of the function is executed if and only if the unit list for the map location (хМар,уМар) is 
not empty. If it is empty, the rest of this stuff is skipped. 


//115% is not empty 

UNITLISTITER iter-mlMap[xMap]L[yMap].ulUnitList.begin(); 
//get iterator to beginning of list 

PUNITINFO pUnitInfo-*iter;//grab the item 


T his is your basic "grab the unit pointer" code, which is in this example several times. Simply set an itera- 
tor to the beginning of the unit list of the map location in question, and then use the overloaded * opera- 
tor to gain access to the item stored there. 


//if this is the current unit 
if(pUnitInfo--pCurrentUnit) 
{ 
//this is the current unit 
if(!bFlash) return;//if flash is "off" don’t render 


| mentioned br1ash (one of the new globals) earlier. T his is where the "flashing" effect of the current 
unit is accomplished. If the topmost unit is the current unit (pCurrentUnit), you check if bFlash is false. 
If it is, return without rendering anything. 


//place the unit 
tsUnit.ClipTile(lpddsDst,rcClip,xDst,yDst,pUnitInfo->iType); 


| know that this is just a single line, but it's an important опе Based on what is stored in the unit's i Type, 
render the appropriate image from tsUni t. 


iter++;//move to the next item in the list 
if(iter--mlMap[xMap]L[yMap].ulUnitList.end()) 
//if the end of the list, this is a single unit 


N ow that the unit is rendered, you must also render the shield next to it. W hich shield image is shown 
depends on two things. T he first is the contents of i Team, giving you which color to use, and the second is 
whether this is a single unit or a stack. T he preceding code moves the iterator (which previously was at the 
beginning of the list) and advances it by 1. If the iterator now sits at the end of the list, you know that 
there is only a single unit here, so the next bit of code is executed. 


{ 
tsShield.ClipTile(lpddsDst,rcClip,xDst+ 
ptShieldOffsetLpUnitInfo->iType].x,yDst+ 
ptShieldOffset[pUnitInfo-»iType].y,pUnitInfo-»iTeam*2); 
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//place the shield 


T his code renders a "single unit” shield. T he image for the shield contains four images: Team1-Single(0), 
Teaml-Stack(1), Team2-Single(2), and Team2-Stack(3). 50, you can use iTeam*2 for single units. 


else//more than one unit...this is a stack 
{ 
tsShield.ClipTile(lpddsDst,rcClip,xDst+ 
ptShieldOffset[pUnitInfo-»iType].x,yDst- 
ptShieldOffset[pUnitInfo-»iType].y,pUnitInfo- 
>iTeam*2+1); 


//place the shield 


If the unit is part of a stack, you use i Team*2+1 for the image number from the shield tileset. 


And that's it for the rendering function. Almost half of it is concerned with rendering the appropriate 
shield. | could have instead used the count method of the list template, but since you dont actually care 
how many units are in the stack, | felt it was a waste. 


EVENT HANDLING 

Last, but certainly not least, we come to event handling. All input for this example is in the way of key- 
presses and can be found under wm_KEYDOwN in the window procedure. T hese keypresses are the only way 
to get out of cs_IDLE and into another game state. 


ук РНСЕ 


W henever the spacebar is pressed during GS_IDLE, you must inform the game that the current unit will 
not be moving this turn. 


case VK_SPACE://do not move unit 
{ 


if(iGameState==GS_IDLE) iGameState=GS_NULLMOVE; 
//only respond when gamestate is GS_IDLE; 
return(0); 
}break; 


T his is a simple event handler. First, make sure that the game state is GS_IDLE. If it is, set it to 65 NULL- 
MOVE, 
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Т he character W is the wait command, telling the game that you might want to move this unit during the 
current turn, but you do not want to move it just now. 


case 'W'://wait to move this unit later 
{ 
//skip this unit for now 
if(iGameState==GS_IDLE) iGameState=GS_SKIPMOVE; 
return(0); 
break; 


Again, this is a very simple handler. Check for &s_IDLE, and set it to GS_SKIPMOVE. 


DIRECTION KEYS 


T here аге 16 of these in total, but I’m only going to show you two of them, since they are all so similar 
(the only difference is the direction to which idMoveUnit is set). Table 18.6 shows what keys initiate 
movement in the various directions. 


Table 18.6 Keys and Directions 


Main Key Secondary Key Direction 
ҮК МИМРАПВ VK_UP SO_NORTH 
VK_NUMPAD9 VK_PRIOR SO_NORTHEAS 
VK_NUMPAD6 VK_RIGHT SO_EAST 
VK_NUMPAD3 VK_NEXT SO_SOUTHEAS 
VK_NUMPAD2 VK_DOWN SO SOUTH 
VK NUMPADI VK END 50 SOUTHWES 
VK. NUMPADA ҮК ПЕРТ SO_WEST 
VK_NUMPAD7 VK_HOME SO_NORTHWES 
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T hese keys were chosen so that the example would work regardless of the state of the N um Lock key. 
W ith this in mind, let's take a look at the case for northward movement, vK_NUMPAD8 and VK UP. 


case VK NUMPAD8: 
case VK UP: 
{ 


if(iGameState--GS IDLE)//gamestate must be GS_IDLE 
{ 


First and foremost, the game must be in сѕ_ тоге, or no key processing should be done, and this keypress 

should be ignored. 
idMoveUnit=ISO_NORTH;//move to the north 
//check the next position 


POINT ptNext-TileWalker.TileWalkt( 
pCurrentUnit-»ptPosition,idMoveUnit); 


N ext, select the appropriate direction for idMoveUnit (150. МОВТН in this case), and assign a POINT 
variable (ptNext) to the next location if this move were allowed by using {Пет ileW alker. Before а move 
is processed, you must first validate it. 


if(ptNext.x»-0 && ptNext.y>=0 && 
ptNext.x«MAPWIDTH && ptNext.y<MAPWIDTH) 
//bounds checking 


T he very first thing to check before allowing this moveto go forward is whether or not the destination 
(ptNext) even exists as a map location. If you have moved out of bounds, the following code is skipped: 


if(mIMap[ptNext.x][ptNext.y].ulUnitList.empty()) 
//if the map location is empty 


{ 
//set the unit in motion 
iGameState=GS_STARTMOVE; 


T he second part of validation requires that you eliminate "illegal" map locations. For the purposes of this 
example, the only illegal map locations are those occupied by units of the opposing team, so if the map 
location at ptNext is empty, the move can go ahead with no problems, and the game state is set to 
GS_STARTMOVE. 


else 
{ 
UNITLISTITER iteremlMap[ptNext.x] 
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[ptNext.y].ulUnitList.begin(); 
//get the first entry in the list 

PUNITINFO pUnitInfo=*iter; 

//get the unit from the list 

if (pUnitInfo->iTeam==pCurrentUnit->i Team) 
//must be the same team 


{ 
iGameState-GS STARTMOVE; 
} 


} 
ibreak; 


If the destination map location is not empty, you proceed to the third part of validation. You must deter- 
mine what team occupies the map location at ptNext. If it is your team (pCurrentUnit-»iTeanm), the 
move can proceed, and the game state can be set to 05 srARTMOVE. If not, the movement command is 
ignored. 


You now have full understanding of the thought process behind IsoH ех18 3.cpp. | hope! have shown 
that linked lists arent as scary as you might first have thought, and that ST L isnt as evil as everyone makes 
it out to be. In our case, it drastically reduces the complexity of the program and also makes it so that you 
dont have to "roll your own" linked lists. 


Oh... you probably want to see what the application looks like, right? Figure 18.11 gives a glimpse T his 
figure really doesnt do it justice, so you just have to run it and play around with it for a while. | think it's 
pretty neat, but then again, | wrote it. 
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Figure 18.11 
Output of IsoHex18 3.срр 


SUMMARY 


It's been along journey, but well worth it. W eve covered coarse object placement and movement, and the 
examples are starting to look game-like. W eve gone from a single unit to multiple units and linked lists. 
After along time in building, you are starting to see some results from all the hard work you've put into 
these isometric components, and they are serving you well. In the next few chapters, you'll refine and 
enhance what you've already got, and by the end, you should have enough information to start work on an 
honest-to-goodness strategy game. 
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Окоекст SELECTION | 511 | 


fter spending so much time on object placement and movement, object selection might seem 

almost anticlimactic, since most of the foundation for the tasks ahead has already been taken care 
of. М evertheless, а good, solid grasp of object selection will enhance your games immeasurably. If you've 
ever played a game that had a clunky interface, you know what | mean. M any game developers tend to pay 
only a passing amount of attention to what matters most— control over your game. | dont mean user 
interface elements (like buttons, windows, and so on), but rather how you select the objects under your 
control, and how you give them orders. Also, I'll introduce you to three very common strategy game fea 
tures: the minimap, zones of control, and the fog of war. 


ТРЕЕ OBJECT SELECTION 


I’m currently using the turn-based tratay came paradigm, and I'm going to stay with it for a while, since it 
makes demonstrating concepts easy. Still, the concepts shown here can be adapted for use in a real-time 
system as well. T he first thing well look at is a very simple object selection algorithm. 


Chapter 18, “O bject Placement and M ovement,” explored a way to control multiple units in example 
IsoH ех18 3. Although it was a very simplistic example, it got the job done. H owever, it left the user rela- 
tively few options as far as organizing unit movement. You could simply move the unit, not move the unit, 
or move the unit later, which isnt much as far as control is concerned. Ideally, you might like to select a 
different unit with the mouse, either by clicking on that unit, or by clicking on the map location contain- 
ing that unit. You'll start with clicking on the map location, because that is easier, and later you'll move on 
to “pixel-perfect” unit selection. 


АРЬЕ OBJECT SELECTION DESIGN 


Before you do any work, you must figure out exactly what you want to accomplish. [п the next example, 
which is based on IsoH ех18 3.cpp (it already has the multiple-unit stuff built into it), you want the fol- 
lowing features: 


= T he ability to click on another unit and have it become the current unit 

= Theability to tell a unit to “fortify” or “hold current position” indefinitely (it gets annoying to press the 
spacebar each turn for units you do not want to move) 

a T heability to “scout” the map by scrolling the screen space 

= T he ability to center the screen on the current unit (in case you were scouting and now you want to find your 
unit again) 


N ow, le's take these one by one, and explore the benefits and pitfalls of making them happen. 
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CuUCK-SELECTING UNITS 


ІП І5ОН ех18 3, you simply looped through all the units, one at a time, moving or not moving them as 
desired. T his method remains a suitable way to do things, so you wont change it. W hat you want to do, 
however, requires that you “short-circuit” this loop after clicking on a unit's map location. T he benefit 
gained is that you help achieve one of the main objectives for this example— more choices in controlling 
units. 


T he pitfalls arent too deep— there are just a few things to think about. First, you have to decide whether 
you are responding to WM_LBUTTONDOWN Or WM_LBUTTONUP. T his isnt a tough choice, but it's a significant 
one. You'll use both, actually, and I'm about to tell you why. 


If you've been working with W indows for a while, you probably use an important feature of it without 
really thinking about it— canceling a button press by moving off it. W henever you click on a button, it 
displays its “down” image, indicating to you that yes, you have pressed the left mouse button over that 
control. Н owever, the action associated with that button does not occur until you release the left mouse 
button, and, more importantly, you must release the mouse button over that same control, or nothing hap- 
pens. 


T hat is sort of what | want to accomplish here If you click the left mouse button, the tile on which the 
mouse rests is recorded. Later, if the left mouse button is released while over that same tile, a click is regis- 
tered, and the appropriate action takes place. L ater on, you'll change this behavior to include unit dragging, 
but for now, it will suffice. So, if the left mouse button is pressed and released within the same map loca- 
tion, the program must perform the appropriate action. D epending on what the map location in question 
contains, the “appropriate action” might differ. 


For unit selection, you are concerned with map locations that contain units belonging to the current team. 
Also, the map location must have a unit that has not moved or received an order earlier in the turn. T his 
will involve some bookkeeping on your part. 


Finally, there might be more than one unit on the map location in question, so you have to allow some 
manner of selecting exactly which unit is to be moved. See? It's getting complicated already, ог at least 
less simple. 


FORTIFICATION/ HOLDING POSITION 


T his item sounds relatively simple, but it has some significant ramifications for the rest of the program. 

T he basic idea here is that you provide some way to tell a unit to stay where it is, indefinitely, until you 
select it again on some other turn. T he benefit is that you will no longer need to press the spacebar every 
turn for that unit, which in turn lowers the "annoyance" factor. T he first issue you need to address in order 
to make this work is that of indication. You must have some way to visually show the player that the unit 
is holding position. M y personal choice is to makea little H that appears on the shield of that unit. 
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T he impact on your code is that there must be a flag in the Unit Info struct that tells you the unit is hold- 
ing position, which is a simple enough matter. Also, you have to add art to the shield bitmap (another sim- 
ple matter), and you need to modify the rendering code. 


T he next little snag is more subtle. Let me paint you a scenario. D uring my turn, | tell one of my units to 
hold position instead of move. T his is fine, so | set the little member of UnitInfo to true N ow, later in 
the same turn, | dick on this same unit, and | should be able to move it, because it hasnt moved yet. N ow, 
lets say | wait until my next turn to click on it and move it. Again, this isnt much of a problem, because 
the unit has been holding position since the beginning of the turn. 


№ ow, let's look ahead. I'm rather confident that later you will want units that move more than a single tile 
per turn. In fact, I’m sure of it. Let's say that the unit | told to hold position has a movement allowance of 
two squares per turn, and that | moved it one square and then told it to hold position. If | were to click 
on it and select it later in the turn, | should be allowed to move it only one square. 


T he concept I'm trying to get across is "movement points.” You havent worried about them, because all 
your units move only one square per turn, but this wont always be so. So, you should add a member to 
UnitInfo to keep track of how many movement points a unit has, even if for now the number is only one. 


T here are other issues: W hat happens when the units holding position come up during the iteration of the 
team’s unit list? D o you just skip that unit's turn? D o you hold off until all the nonholding units have 
been moved? W hat if all of a player's units are holding position? Do you just skip his turn, because there 
is nothing to move? Answering these questions now, instead of when youre in the middle of writing the 
program, will help you immensely and will avoid problems when you are testing the program. 


To answer the question of what to do when a holding unit comes up in rotation, it would be unfair to 
skip that unit's turn, since the player might still want to move that unit later, and he should be given a 
chance to do so.To do this, you either have to leave the unit in the team list, which means you'll have to 
change how as. NExrUNITT selects its next unit, or you can keep units that are holding position in another 
list, which means you'll have to change the way you select units with the mouse (which you havent written 
yet anyway, so it's no big deal). 


To answer the question of what to do if all of a player's unit's are holding position, it would be grossly 
unfair (and not very fun) to exclude a chance for a player to change his orders. As long as at least one unit 
has been moved, you can skip the units that are holding position and progress to the other player turn, 
since the player had a chance to change orders if he wished. If no unit has been moved, the program 
should go into a semi-paused state so that the player can change his unit's orders if he wishes, or just click 
a button or press a key to skip his turn. T his will be pretty simpleto implement. You'll just need an extra 
bool global that you set to false at the beginning of a player's turn, set to true if a unit is moved (or given 
an order) during that turn, and check for at the end of the player's turn. 
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SCOUTING 


Compared to the last two items, this one is pretty simple. You want to be able to look around the map 
before you decide what you're doing with a unit. T his feature is an absolute must for most types of games. 


You have two basic methods to choose from. O ne is the "mouse at the edges" scrolling method (which 
you've done in previous examples), and the other is the “click on an empty square to move screen space" 
method. For a change, | want to usethe second method (not that there is anything wrong with the first 
one). T his brings to mind the question of what constitutes an empty square. For your purposes, an empty 
square is any square that does not have a unit belonging to the current player's team. W hen clicked (you 
will follow the same rules as for the first item), the screen space will be centered on the map location in 
question. 


T hat's about it for scouting. It's not tough, it just requires playing with the screen-space anchor. 


CENTERING ON THE CURRENT UNIT 


Because you added the ability to scout the surroundings in the preceding item, it is entirely possible that 
the screen space might move quite far afield, and it’s quite likely that you will forget where the heck that 
unit you were about to move is. T his happens to me all the time іп the games | play. Almost all games give 
you the ability to quickly center screen space back on the current unit. (As for those that dont, let's just 
say those CD s gather а lot of dust in my house) 


In this program, centering is simple. D uring 65 тоге, if the C key is pressed, you have screen space center 
on the current unit's position, exactly the same way it does during GS_NEXTUNIT. 


SIMPLE OBJECT SELECTION 
IMPLEMENTATION 
Go ahead and load up 150Н ех19 1.cpp. In this example, I've implemented all of what was listed during 


the design discussion. V isually, you wont be able to tell the difference between this example and 
IsoH ех18 3.cpp (the example upon which this one is based), except in a few places. 


Game STATES 


M ost of the changes in IsoH ех19 1 consist of modifications to existing game states and the addition of 
new game states. T he rest of the application is left untouched for the most part. T here is a new tileset 
(tsPressEnter) and a few extra globals, but l'II shed light on them as they are used. 


Table 19.1 lists the game states for this example. As you can see, most of them are carried over from 
IsoH ех18 3. Because of the new capabilities, most of the game states have been modified, even if very 
slightly. 
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Table 19.1 IsoHex19 1 Game States 


&S. ІШПЕ GS. SKIPMOVE 

GS STARTTURN GS HOLDPOSITION' 
GS ENDTURN 65 С СКЕ ШЕСТ" 
GS_NEXTUNIT GS CLICKCENTER' 
GS STARTMOVE GS CLICKSTACK" 
GS. DOMOVE GS PICKUNIT* 
GS_ENDMOVE 

GS_NULLMOVE “Мем game state 


As you can see, there are only five new game states, but the functions of a few of the old ones have 
changed significantly to compensate for the changes. Let's take them one at a time. 


GS_IDLEeE 


Asin [50Н ex18 3, the bulk of the time is spent in cs Ірге. H owever, GS_IDLE is now performing dou- 
ble duty. T he current unit (pCurrentUnit) can be NULL, indicating that no unit is currently selected, but 
the player's turn isnt over yet. T his happens when all of a player's units are holding position. I'm going to 
quickly go through this game states code and annotate the changes | have made. 


case GS_IDLE://the game is idling; update the frame, but that’s about it. 
{ 


DWORD dwlimeStart=GetTickCount();//get the frame start time 
//scroll the frame (0,0) 

Renderer.ScrollFrame(0,0); 

//toggle unit flash 

bFlash=!bFlash; 
//if the current unit is not null 
if(pCurrentUnit!-NULL) 

{ 


//add the tile in which the current unit lives 
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Renderer.AddTile(pCurrentUnit->ptPosition.x, pCurrentUnit- 
>ptPosition.y); 
} 


T his is the first change. Before, no matter what, pcurrentUnit was always non-NULL when you were in 
GS IDLE. You can no longer make that assumption, so you must check to see № pcurrentUnit is not 
NULL. If it is, you add its tile position to the renderer for updating. 


//update the frame 
Renderer.UpdateFrame(); 
//if the current unit IS null 
if(pCurrentUnit--NULL) 
{ 
//show the end of turn marker if bflash is true 
if(bFlash) tsPressEnter.PutTile(lpddsBack,0,0,iCurrentTeam) ; 


T his is the flip side of the preceding change If pcurrentUnit is NULL, the player can choose to select a 
unit with the mouse or press Enter to indicate that he does not wish to move any of his units. W hile in 
this situation, you must somehow clue the user in that he is in this state. | chose to do this by flashing 
"Press Enter” in the player's color (blue or red) in the upper-left corner of the screen. T he images for this 
text exist in tsPressEnter and come from PressEnter.bmp. In a real situation, you probably want to have 
actual text, but implementing a font engine for such a small part seemed wasteful to me. Also of note, the 
text is blitted to the back buffer afte the renderer has updated the frame, so you dont have to worry about 
updating it next frame. 


//flip to show the back buffer 

lpddsMain-»Flip(O,DDFLIP WAIT); 

//wait until 200 ms have passed 

while(GetTickCount()-dwTimeStart«200); 
}break; 


GS_IDLE ends as it did before, waiting for 200 milliseconds before returning. Т he changes to GS_IDLE are 
small, but they do have important impact as far as how the program looks. 


GS_STARTTURN 


T his game state has also been modified slightly from its older version. [50Н ех18 3 had no movement 
points, but this example does. [п fact, just to make things interesting, | made one unit able to move two 
squares per turn, and the other unit just one. 


case GS STARTTURN://start the current team's turn 


OBJECT SELECTION S17 


PUNITINFO pUnitInfo;//variable to check for the team’s units 
UNITLISTITER iter;//iterator for the main unit list 
for(iter-MainUnitList.begin();iter!-MainUnitList.end(); 
iter++)//iterate through the main unit list 


pUnitInfo-*iter;//grab the unit from the list 
if (pUnitInfo->iTeam==iCurrentTeam) 
//does this unit belong to the current team? 


//give the unit a movement point 
pUnitInfo->iMovePoints=l+pUnitInfo->iType; 


T his is one change to GS_STARTTURN, setting each unit's iMovePoints member to 1Туре+1. Since iType 
is either 0 or 1, iMovePoints will be set to 1 or 2. 


//add this unit to the team list 
TeamUnitList.push back(pUnitInfo); 


} 

//set moved unit flag to false 

bMovedUnit=false; 

//set the next gamestate 

iGameState=GS_NEXTUNIT; 
}break; 


A few lines from the bottom is another change— setting pMovedunit to false T he bMovedunit variable is 
anew global. It records whether or not a player has given a unit a command during his turn— that is, by 
going to GS_STARTMOVE, GS_NULLMOVE, Or GS. HOLDPOSITION.T he GS_SKIPMOVE game state does not set 
this variable to true, because telling a unit to wait for orders later is not considered an actual order to do 
something. bMovedUnit comes into play later in 65 NEXTUNIT. 


а-в NEXTUNIT 
T his game state was modified more than most because of its central role in the program. T he first factor 
that | had to take into account was that of units that were holding position (bHo1ding--true). Another 
factor was the state of bMovedUnit when there were no units left to move. 
case GS NEXTUNIT://select the next unit as the current unit 

{ 


//set current unit to NULL 
pCurrentUnit=NULL; 
if(TeamUnitList.empty())//if the team unit list is empty 
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//if a unit has been moved, send to end of turn 
if (bMovedUnit) 
{ 


iGameState-GS ENDTURN;//end the turn 


//send to GS IDLE 
iGameState-GS IDLE;//send to idle state 


T his code takes into account the status of pMovedUnit. If bMovedUnit is true, a unit has been given an 
order during this player's turn, so it is safe to end his turn. If it is false the player must be given a chance 
to select a unit with the mouse and give it an order, so the program proceeds into as. тоге (with 
pCurrentUnit--NULL). 


else 
{ 

//turn is not over 
UNITLISTITER iter=TeamUnitList.begin(); 
//get the first unit in the team list 
pCurrentUnit=*iter;//grab the unit from the list 
TeamUnitList.pop_front();//remove the unit from the list 
//check to see if this unit is holding position 
if(pCurrentUnit-»bHolding) return;//go to next unit 
]Map[pCurrentUnit-»ptPosition.x] 
[pCurrentUnit->ptPosition.y].ulUnitList.remove( 
pCurrentUnit);//remove the unit from the map location 
lMap[pCurrentUnit-»ptPosition.x] 
[pCurrentUnit-»ptPosition.y].ulUnitList.push front( 
pCurrentUnit);//place unit at the top of the map loca- 
tions unit list 
POINT ptPlot=TilePlotter.PlotTile(pCurrentUnit->ptPosition); 
//plot the unit's location 
POINT ptScreen=Scroller.WorldToScreen(ptPlot); 
//translate into screen coordinates 
if(!PtInRect(Scroller.GetScreenSpace(),ptScreen) ) 

//check to see if point is within screenspace 


//not on screen 
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ptPlot.x--(Scroller.GetScreenSpaceWidth()/2); 
ptPlot.y-=(Scroller.GetScreenSpaceHeight()/2); 
//set the anchor 

Scroller.SetAnchor(&ptPlot) ; 
Renderer.AddRect(Scroller.GetScreenSpace()); 


} 
iGameState-GS IDLE;//set to idling gamestate 
} 
}break; 


T he rest of GS_NEXTUNIT remains the same, with one exception. If the first unit in TeamUnitList is hold- 
ing position, you skip this unit (by simply returning from the function— the unit has already been moved 
from the list) and wait for cs МЕХТИМІТ to be executed again. О therwise, you process the unit as normal, 
Set pCurrentUnit equal to it, and move into Gs. IDLE. 


GS_STARTMOVE AND G5 NULLTYIOVE 


T hese game states change almost imperceptibly, so I’m not going to waste space describing them here. You 
can check them out in the code if you want. T he main change for these game states is that they set 
bMovedUnit to true in addition to their former roles. 


Go _HOLDPOSITION 


T his is one of the new keyboard commands holding position. T his can occur only during в$_тотЕ when 
pCurrentUnit is non-NULL and the H key is pressed. W hen this happens, the game moves into Gs HOLD- 
POSITION. 


case GS HOLDPOSITION://tell unit to hold position 
{ 
//set holding flag 
pCurrentUnit->bHolding=true; 
//show the holding unit 
Renderer. AddTile(pCurrentUnit->ptPosition.x, pCurrentUnit- 
>ptPosition.y); 
pCurrentUnit=NULL; 
bFlash=true; 
//set next gamestate 
iGameState=GS_NEXTUNIT; 


T his game state is comprised of two parts. T his first part modifies the unit data (setting the bHolding 
member to true), tells the renderer to update the tile on which the current unit is resting, sets 
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pCurrentUnit tO NULL, Sets bFlash to 
state, which is GS_NEXTUNIT. 


//scroll the fra 


false (you dont want flashing right now), and sets the next game 


DWORD dwTimeStart-GetTickCount();//get the frame start time 


e (0,0) 


Renderer.ScrollFrame(0,0); 


//update the fra 


е 


Renderer.UpdateFrame(); 
//flip to show the back buffer 


lpddsMain->Flip(0 

//wait until 500 

while(GetTickCou 
break; 


T his second half of GS_HOLDPOSITION 
updated. You wait for 500 milliseconds 


,DDFLIP WAIT); 
ms have passed 
t()-dwlimeStart<500); 


is taken almost verbatim from as_ENDMOve, where the display is 
before proceeding. T his is so that the player can actually see that 


his unit is now holding position for a split second before proceeding to the next unit. 


GS _ CLICHABSELTECT 


GS_CLICKSELECT, along with GS_CLICKCENTER, GS_CLICKSTACK, and GS_PICKUNIT, Comprises the large 


addition of functionality in this exampl 
figure 19,1. 


e T hese game states handle all the mouse input once it occurs. See 


Figure 19.1 
Additional Game States 


Click on 
Em 


Click on 


a 
of Units 
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GS CLICKSELECT acts as a router of sorts. | decided I'd rather do that than put all the conditional code 
(theres a lot of it) into the handler for ww LaurroNpowN and wM_LBUTTONUP.T his game state, despite the 
appearance, contains alot of code, mainly because of all the testing that needs to be done in order to 
decide what action to perform once а map location is clicked. 


First, GS_CLICKSELECT checks if the map location in question is empty. If it is, the program gets sent to 
GS CLICKCENTER. If not, it then checks to see what team the units within that location belong to. If they 
belong to the other player, again the program is sent to aS_CLICKCENTER. Otherwise the current player 
owns the units within that location. If it is a single unit, cs cL TCKsELECT attempts to make it the current 
unit (checking if the unit has any movement points before doing so). If it is a stack of units, the program 
goes into 65 CLICKSTACK. 


case GS CLICKSELECT: 
{ 


//check map location for emptiness 
if(miMap[ptClick.x]£ptClick.y].ulUnitList.empty()) 
{ 

//map location is empty 

//we want to center on this map location 

iGameState=GS_CLICKCENTER; 


First, check the unit list at the map location stored in рст іск for emptiness. If the unit list is empty, 
send the game into GS_CLICKCENTER. 


else 
{ 
//map location is not empty 
//look at top of list 
UNITLISTITER 
iter-mlMap[ptClick.x][ptClick.y].ulUnitLlist.begin(); 
PUNITINFO pUnitInfo-*iter; 
//check if this unit belongs to the current team 


T he unit list is not empty, so the mouse has clicked on an occupied square, and you must determine what 
team the units there belong to. T he preceding code grabs the unit at the beginning of the list. 


if (pUnitInfo->iTeam==iCurrentTeam) 
{ 
//belongs to current team 
//one unit? 
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Aha!T he units in question belong to the current team! T his leaves the question of how many units there 
are and whether any of them receive orders. 


if(mlMap[ptClick.x][ptClick.yJ.ulUnitList.size()7-71) 
{ 
//a single unit (already contained in pUnitInfo) 
//is this the current unit? 
if(pUnitInfo--pCurrentUnit) 
{ 
//this is the current unit 
iGameState-GS IDLE; 
//return to the neutral gamestate 


T his piece of code has detected a single unit belonging to the current team. Before proceeding, you check 
to sæ if this unit is the same as pCurrentUni t. If it is, you need do nothing, and can just go back to 
GS IDLE. 


else 
{ 
//this is not the current unit 
//does this unit have any movement points left? 
if (pUnitInfo->iMovePoints>0) 
{ 
//has movement points left 
//push the current unit to front of team 
if (pCurrentUnit) 
TeamUnitList.push_front(pCurrentUnit) ; 
pCurrentUnit=NULL; 
//set holding to false for the new unit 
pUnitInfo->bHolding=false; 
//remove new unit from team list 
TeamUnitList.remove(pUnitInfo); 
//put new unit in front of team list 
TeamUnitList.push_front(pUnitInfo) ; 
//go to gs_nextunit 
iGameState=GS_NEXTUNIT; 
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N ow that you have determined that it is not the current unit, the next test is to see whether the unit has 
any movement points left. If it does, you should set this unit up to be the next selected. T he way to do this 
is to first put pcurrentUnit back into TeamUnitList if pCurrentUnit is non-NULL. N ext, you put the 
new unit at the head of the list and send the program into 05 NEXTUNIT. 


else 

{ 
//does not have movement points left 
//go back to gs idle 
iGameState-GS IDLE; 


T his bit of code is executed when no movement points are left for the unit. It simply returns you to 
GS IDLE. Alternatively, you could have it send the program into Gs CENTER. 


else 

{ 
//a stack of units 
iGameState-GS CLICKSTACK; 


T his bit is run when more than one unit is in the map location clicked on. You are sent into 65 cLICK- 
STACK, Where more processing will occur. 


else 

{ 
//does not belong to current team 
iGameState=GS_CLICKCENTER; 
//we want to center on this map location 


} 
}break; 


Finally, this code executes when the units within the map location do not belong to the current team. For 
all intents and purposes, it is treated as though it were an enpty square by sending the program into 
GS_CLICKCENTER. GS_CLICKSELECT might be really long, and perhaps it isnt the best way to accomplish 
the goals. Indeed, а few more game states could have been added to make the code a bit cleaner. М ауре I'll 
do that in a future example 
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аш CLICHKCENTEFR 


T his game state is small and simple From Gs_cLICKSELECT, there are a few places where the program gets 
sent into this game state. All you have to do here is center the screen on the location clicked. 


case GS_CLICKCENTER: 
{ 


//center on clicked tile 
POINT ptPlot-TilePlotter.PlotTile(ptClick);//plot tile 
//adjust by half screenspace 
ptPlot.x--(Scroller.GetScreenSpaceWidth()/2); 
ptPlot.y--(Scroller.GetScreenSpaceHeight()/2); 
Scroller.SetAnchor(&ptPlot);//set anchor 
Renderer.AddRect(Scroller.GetScreenSpace()); 
//return to GS IDLE 
iGameState-GS IDLE; 

}break; 


You'll probably notice that this looks a great deal like the centering code of as NExruNrr. It should, since 
| mostly cut and pasted it here. In fact, | probably could have just had сѕ_ умтт go to this game state and 
eliminate the centering code there. 


Go CLICKS THCK 


In order to explain fully what goes on in GS_CLICKSTACK, | must first discuss a few new globals, and a new 
U I feature | added with this example As | discussed earlier, you must provide some way of selecting a unit 
when a stack of units is clicked. Figure 19.2 shows this (the stack of units to the right of the window is 
the one that | clicked on to bring up this window). If you have ever played strategy games with stackable 
units, you have undoubtedly seen similar windows. 
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Figure 19.2 


The unit selection 
window 


GELECT 
WINDOW GLOSALS 


To make this window happen, | added several globals: 


//unit selection variables (for selecting stacks of units) 

RECT rcSelectWindow;//the selection window 

POINT ptCellSize;//size of selection cell 

PUNITINFO SelectUnitList[20];//unit selection list (max of 20 units) 
POINT ptUnitOffset;//offset for placing units in the selection window 
DWORD dwSelectWindowColor;//color for the selection window 


rcSelectWindow IS а RECT that defines where and how big the selection window is. At first, | considered 
putting it in a corner of the screen, but | wound up putting it in the middle, because it makes the display 
more balanced. 


ptCel1Size keeps track of how large а cell of the selection window is. A cell can contain one unit, and 
the selection window is five cells wide by four cells high. T his lets you select from up to 20 stacked units 
(since each player has only 20 units, this will work just fine). If the player could have any number of units, 
you would have to modify the selection window, ether to have more than one page or to have some sort of 
way to scroll through the units. ptCe11Size is based on the combined extents of all the units (using 
UnionRect). 


SelectUnitList 15 an array, not a linked list, that stores pointers to all the units to be shown within the 
selection window. A NULL specifies that there is no unit in a given cell. ptunitoffset helps place the unit 
within a cel. Since the images for your units are anchored at the center, you must have a way of centering 
the unit within the cell. ptunitoffset allows you to do that. After the combined extent for the units is 
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calculated, ptUnitOffset is set to -left and -top of that extent. dwSelectwWindowColor just keeps track 
of what color to fill the window with. | picked a 75% gray since it is a common color іп W indows and it 
doesnt interfere with any of the colors in the units. 


SELECT WINDOW INITIALIZATION 


All of the following was taken from Prog_Init.T his is the only code added to that function this time. 
You set up all the select window variables before you get started so you wont forget later. 


//set up the selection window variables 

DDPIXELFORMAT ddpf; 

DDPF_Clear(&ddpf); 

lpddsMain-»GetPixelFormat(&ddpf);//grab pixel format 
ddpf.dwRBitMask-(ddpf.dwRBitMask*3/4)&(ddpf.dwRBitMask);//calculate 3/4 red 
ddpf.dwGBitMaske(ddpf.dwGBitMask*3/4)&(ddpf.dwGBitMask);//calc 3/4 green 
ddpf.dwBBitMaske(ddpf.dwBBitMask*3/4)&(ddpf.dwBBitMask);//calc 3/4 blue 
//make select window color 

dwSelectWindowColor-ddpf.dwBBitMask | ddpf.dwRBitMask | ddpf.dwGBitMask; 


| did the simplest thing first— namely, calculate the color of the select window. Basically, | just grabbed the 
pixel format and multiplied the color masks by three-fourths, getting a nice 75% gray tone. 


//calculate the cell extent 

RECT rcCell; 
CopyRect(&rcCell,&tsUnit.GetTilelist()[0].rcDstExt); 
UnionRect(&rcCell,&rcCell,&tsUnit.GetTilelist()[1].rcDstExt) ; 
rcCell.righte--(tsShield.GetTileList()[0].rcDstExt.right- 
tsShield.GetTileList()[0].rcDstExt.left); 


N ow move on to calculating the cell size; doing so will help you calculate the window size later. T he first 
task is to calculate the combined extents of the units. You have only two unit types right now, but you can 
see how it would be simple to add others. After the rectangles are combined, you add the width of the 
shield image so that you can also show a shield in the selection window without overlapping other units. 


//cell size 
ptCellSize.xercCell.right-rcCell.left; 
ptCellSize.y-rcCell.bottom-rcCell.top; 
//unit offset 
ptUnitOffset.x--rcCell.left; 
ptUnitOffset.y--rcCell.top; 


T his is where ptCe11Size and ptUnitOffset are initialized. ptCe11Size is assigned to the differences 
between right and left and bottom and top, whereas ptunitoffset is set to - left and -top (since гсСе11 
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contains negative values in 1eft and top because it is an extent). 


//calculate select window rect 
SetRect(&rcSelectWindow,0,0,ptCellSize.x*5,ptCellSize.y*4); 

//center the select window 

OffsetRect(&rcSelectWindow, 320-rcSelectWindow.right/2, 240-rcSelectWindow.bot- 
tom/2); 


Finally, you can set up the кест containing the position of the selection window. First, you place it with 
left and top at 0 and then offset it to a centered position. N ow, all the select window stuff is set up and 
ready to use later. 


Back to GS_CLICKSTACK.T he following code is run after a mouse click has been registered and GS_CLICK- 
SELECT decides that the map location in question contains a stack of units. T he job of GS_CLICKSTACK is 
simple set everything up so that the program has enough information to show the selection window. 


case GS CLICKSTACK: 
{ 
//prepare the stack 
int count; 
for(count=0;count<20;count++)//clear out the list 
SelectUnitListLcount J=NULL; 
//reset count to 0 
count=0; 


First and foremost, you must ensure that SelectUnitList is empty (all items are NULL) so that you dont 
erroneously have a unit from some other map location shown in the window, which would be bad (or, at 
least, a bug). 


//iterate through the list of units at the current map location 
UNITLISTITER iter;//iterator 
PUNITINFO pUnitInfo;//unit info 
for(iter-mlMap[ptClick.x][ptClick.y].ulUnitList.begin(); 
count<20 && 
iter!-mlMap[ptClick.x][ptClick.y].ulUnitList.end(); 
iter++)//iterate through list 


{ 


pUnitInfo-*iter;//grab the unit 
//place unit in list 
SelectUnitListLcount]=pUnitInfo; 
//add 1 to count 

count++; 
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T his for loop might seem а little weird, since it doesnt follow the usual for loop pattern (1 put two con- 
ditions in its second part). T his is the basic “iterate through a list” loop, with a "dont look at more than 
20" part added. T he variable count starts at 0 and is used as an index into the SelectUnitList array. For 
each unit found at this map location, add it to SelectUnitList, and add 1 to count. 


//send to next gamestate 
iGameState-GS PICKUNIT; 
break; 


T hats it for 65_С11СК$ТАСК. After it has completed its assigned tasks, it moves to aS_PICKUNIT, which is 
discussed next. 


GS_PICKUNIT 


T his game state displays the selection window every frame, and that's about it. It's kind of like a special- 
ized render function for the select window. It's important for me to note that the select window is rendered 
onto the back buffer (1рааѕваск) after the screen has been updated. T his means it has to be fully redrawn 
every frame. Sure, there were other ways to do it, but this way was the quickest. 


case GS PICKUNIT: 
{ 
//no scrolling 
Renderer.ScrollFrame(0,0); 
//update frame 
Renderer .UpdateFrame(); 


You have to update the display before rendering the select window, and that’s what these two lines do. 
T he display is scrolled by 0 (a necessary step), and then the frame is updated, even though there is no 
update list. 


//place select window onto display 

DDBLTFX ddbltfx; 

DDBLTFX Clear(&ddbltfx); 

ddbltfx.dwFillColor-dwSelectWindowColor; 

lpddsBack-»Blt(&rcSelectWindow,NULL,NULL,DDBLT. WAIT | 
DDBLT. COLORFILL,&ddbltfx); 


N ext, you have to clear out the selection window rectangle with the color in duselectWindowColor.T his 
is just the basic "color fill a rectangle" code taken from Part 1 of this book. 


//show the units 
int cellx,celly;//cell position 
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int се11 пит; / 
int pixelx,pi 


for(celly=0;celly<4;celly++) 


{ 
for(cel 
{ 


/number of the cell 
xely;//pixel position 


1х=0; се11х<5 ; се11х++) 


cellnumecellx*celly*5;//calculate the cell number 


N ow you get into the fun part, looping through all the units in SelectUnitList. First, you set up a set of 
nested loops (се11у and ce11x) and calculate the cell number (се11х-се11у%5). Finally, you can check 


for a unit. 


//check that the unit exists 
if(SelectUnitList[cellnum]) 
{ 


T he bulk of the code happens here, on the inside of the nested loop, and only if there is a unit present in 


the current cell. 


//calculate pixel position 
pixelxercSelectWindow.left*ptCellSize.x*cellx; 
pixely=rcSelectWindow.toptptCellSize.y*celly; 
//plot the unit’s position 
pixelx+=ptUnitOffset.x; 
pixely+=ptUnitOffset.y; 
//put the unit 
tsUnit.PutTile(lpddsBack,pixelx,pixely, 
SelectUnitList£cellnum]->iType); 


First you do the easy part: plotting the cell’s location. (It’s easy. Because the cells are rectangular, you just 


multiply by ptce11Size's x and y. 


After that you offset by ptUnitoffset, which centers the unit in the 


cell. Finally, you place the unit there, and the unit is rendered! 


//move 
pixel x 


the pixel to place shield 
t=ptShieldOffset[SelectUnitListLcellnum]->iType].x; 


ріхеіуч 


N ow you have to place the shield, 
tion you are plotting at by the pts 


t=ptShieldOffset[SelectUnitListL[cellnum]->iType].y; 


which is a bit more conditional. To set it up, you move the pixel posi- 
hieldOffset of the unit you just rendered. T hen you are just left with 


the task of deciding which shield to render with it. For this example, | added a new shield with a check 
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mark in it, indicating that the unit has already been moved this turn. T his shield is shown only in the selec- 
tion window, not anywhere else. 


//place appropriate shield 
if(SelectUnitList[cellnum]-»bHolding) 
{ 
//unit is holding 
tsShield.PutTile(lpddsBack,pixelx,pixely, 
iCurrentTeam*2+4) ; 


T his is simple enough. If the unit is holding position (bHo1ding--true), you show the "| am holding" 
shield, which is image numbers 4 and 6, SO iCurrentTeam*2+4. 


} 

else 

{ 
//unit is not holding 
if(SelectUnitList[cellnum]-»iMovePoints) 
{ 


T he unit is not holding, so you check to see if it has any movement points left. If it does, you put the 
normal shield, which is image 0 or 2. 


//unit has movement points left 
tsShield.PutTile(lpddsBack,pixelx,pixely, 
iCurrentTeam*2) ; 


else 


T he unit is not holding, nor does it have any movement points left. T he images for the "| have moved" 
shield are 8 and 10. 
//unit does not have move points left 


tsShield.PutTile(lpddsBack,pixelx,pixely, 
iCurrentTeam*2+8) ; 
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//flip 
lpddsMain->Flip(0,DDFLIP_WAIT); 
}break; 


And, for the coup de grace, flip the primary surface so that the user can see the lovely select window you 
have made! 


RENDERFUNC 


T he rendering function, too, has undergone some changes, mainly in adding some checks to 
pCurrentUnit, but also in checking the top of a map location's stack to see whether or not the unit is 
holding position. 


void RenderFunc(LPDIRECTDRAWSURFACE7 1раа505%, RECT* rcClip, int xDst, int yDst, 
int xMap, int yMap) 
{ 

//put background tile 

tsBack.ClipTile(lpddsDst,rcClip,xDst,yDst,0); 


Of course, no matter what, the background tile is always shown. 


//check for an empty list 
if(!mIMap[xMap]LyMap].ulUnitList.empty()) 
{ 


If the unit list at this map location is empty, the rest of the function is skipped. O therwise, all the unit 
rendering code shown next is executed. 


//list is not empty 

//get iterator to beginning of list 

UNITLISTITER iter=m1lMapL[xMap]LyMap].ulUnitList.begin(); 
PUNITINFO pUnitInfo-*iter;//grab the item 

//if this is the current unit 
if(pUnitInfo--pCurrentUnit) 

{ 


//this is the current unit 
if(!bFlash) return;//if flash is "off" don't render 


First, you grab the unit from the top of the stack and check to see if it is the current unit. If it is, and 
bFlash Is false, nothing needs to be rendered, so just return. If not, you must render the unit. 


tsUnit.ClipTile(lpddsDst,rcClip,xDst,yDst,pUnitInfo-^iType);//place the unit 
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iter++;//move to the next item in the list 
if(iter--mlMap[xMap]LyMap].ulUnitList.end())//if the end of the 
list, this is a single unit 


{ 


T he next thing to check is whether or not this map location contains a single unit, or a stack, by moving 
to the next unit in the map locations list and checking that against the end of thelist. If you have reached 
the end of thelist, you know that this is the only unit at the map location in question. 


if(pUnitInfo->bHolding)//if holding position 
{//holding 
tsShield.ClipTile(lpddsDst,rcClip, 
xDsteptShieldOffset[pUnitInfo-»iType].x, 
yDst*ptShieldOffset[pUnitInfo-»iType].y., 
pUnitInfo->iTeam*2+4);//place the shield 


T he shield can be one of two states— holding position or normal. If bHoiding is true for the unit, render 
the H shield (either image 4 or 6). 


} 
else 
{//not holding 
tsShield.ClipTile(lpddsDst,rcClip, 
xDsteptShieldOffset[pUnitInfo-»iType].x, 
yDst*ptShieldOffset[pUnitInfo-»iType].y., 
pUnitInfo->iTeam*2);//place the shield 


If it isnt holding position, render the normal shield (image 0 or 2). 


else//more than one unit...this is a stack 
{ 
if(pUnitInfo->bHolding)//if holding position 
{//holding 
tsShield.ClipTile(lpddsDst,rcClip, 
xDsteptShieldOffset[pUnitInfo-»iType].x, 
yDst*ptShieldOffset[pUnitInfo-»iType].y., 
pUnitInfo->iTeam*2+5);//place the shield 


In the case of a stack, the holding position images are 5 and 7, but choosing between holding and normal 
is exactly the same. 
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else 
{//not holding 
tsShield.ClipTile(lpddsDst,rcClip, 
xDsteptShieldOffset[pUnitInfo-»iType].x, 
yDsteptShieldOffset[pUnitInfo-»iType].y, 
pUnitInfo->iTeam*2+1);//place the shield 


Finally, if thetop of a stack is not holding position, place the normal shield (image 1 or 3) from the 
shield tileset. 


HANDLING INPUT 


In this example, most of the keyboard input remains the same, except that now there is a new check for 
pCurrentUnit being NULL (which means that keyboard input is being ignored). Also, there are new han- 
dlers for the H key and the C key, which respectively bring about the hold position and center on unit 
commands. T hese key handlers are very simple (they just move from game state to game state), and you 
can take a look at them in the windowproc if you like. 


M ainly, | want to discuss here the mouse input that | incorporated into this example. O nly two game 
states respond to mouse input: GS_IDLE and Gs_PICKUNIT. All other game states are ignored as far as the 
mouse is concerned. 


КМГ LESUJUTTOND ом 
W hen the left mouse button goes down, only cs. тоге responds to it. T his response simply grabs the cur- 
rent map position. 


case WM LBUTTONDOWN://beginning of click-select 
{ 


//process differently, depending on gamestate 
switch(iGameState) 
{ 
case GS_IDLE: 
{ 


//grab the mouse position 

POINT ptCursor; 
ptCursor.x=LOWORD(1Param) ; 

ptCursor. y=HIWORD(1Param) ; 

//use the mousemap to get click position 
ptClick=MouseMap.MapMouse(ptCursor); 
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}break; 
} 
return(0);//handled 
break; 


T heres not much to this code. M ainly, you just grab the cursor position from 1Param and use the 
M ouseM ap to determine the current map location. 


WM_LBUTTONUF 


W hen the mouse button is released, the code is a bit lengthier. Both GS_IDLE and Gs_PICKUNIT respond 
to this input. 


case WM_LBUTTONUP://end of click-select 
{ 

//process differently, depending on gamestate 

switch(iGameState) 

{ 

case GS_IDLE: 

{ 

//grab the mouse position 
POINT ptCursor; 
ptCursor.x=LOWORD(1Param) ; 
ptCursor. y=HIWORD(1Param) ; 
//use the mousemap to get click position 
POINT ptMap=MouseMap.MapMouse(ptCursor) ; 
//check map position against ptClick 
if(ptMap.x==ptClick.x && ptMap.y==ptClick.y) 
{ 


//set gamestate to GS_CLICKSELECT 
iGameState-GS CLICKSELECT; 


} 
ibreak; 


W hen the left button is released during GS_IDLE, you again grab the mouse position from 1Param. 
H owever, you dont stop there You also check to see that this position is the same one you pressed the left 
button on. If it is, you proceed to GS_CLICKSELECT. If it isnt, you remain in Gs IDLE. 


GS PICKUNIT is another story. It has to do with the select window and has nothing to do with the map. 


case GS PICKUNIT: 
{ 
//grab the mouse position 
POINT ptMouse; 
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ptMouse. x=LOWORD(1Param) ; 
ptMouse. y=HIWORD(1Param) ; 


First, as with all mouse handlers, you must grab the position from 1Param. М ost of the time, you cant get 
around this. . . it's just a part of programming. 


//check to see if the click was within the select window 
if(PtInRect(&rcSelectWindow,ptMouse)) 
{ 


T he first check is to see whether the mouse is in the selection window. If it is, the following code is run. If 
not, you skip a bit. 


//within the select window 

//determine which cell was clicked 
ptMouse.x--rcSelectWindow.left;//subtract top left of the window 
ptMouse.y-=rcSelectWindow. top; 

ptMouse.x/=ptCellSize.x;//divide by cellsize 
ptMouse.y/-ptCellSize.y; 

int cellnum=ptMouse.x+5*ptMouse.y;//calc cell number 


T hese few lines of code are kind of like a custom rectangular M ouseM ap. First, you subtract the left and 
top of the selection window from the тоџѕе x and y, getting the relative x and y pixel coordinates of the 
mouse within the window. x will now be from 0 to the width of the selection window (minus 1), and y 
will now be from 0 to the height of the selection window (again, minus 1). After the subtraction, divide 
each by the cell's width and height to get the call’s column and row. Finally, based on cell column and row, 
figure out which cell you are pointing to with the mouse. 


//check for a NULL 
if(SelectUnitList[cellnum]2-NULL) 
{ 


//empty cell 
//do nothing 
return(0); 


N ow that you have the cell number, you check to see if that cell contains NULL. If it does, the cell is 
empty, so you treat it as a disabled button and do nothing. 


else 
{ 


//non-empty cell 
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//check if the unit has any movement points left 
if(SelectUnitList[cellnum]-»iMovePoints--0) 
{ 


//no movement points 
//do nothing 
return(0); 


T he unit here is non-NuLL but has no movement points left, so again you do nothing. 


else 
{ 
//check for holding position 
if(SelectUnitList[cellnum]-»5bHolding) 
{ 
//set holding to false 
SelectUnitList[cellnum]-^»bHolding-false; 
} 
//remove this it from the team list 
TeamUnitList.remove(SelectUnitList[cellnum]); 
//re-add this it to the team list at the beginning 
TeamUnitList.push front(SelectUnitList[cellnum]) ; 
//select next it 
iGameState-GS NEXTUNIT; 
//add entire screen to update rect 
Renderer.AddRect(Scroller.GetScreenSpace()); 


Finally, if the unit in the call is non-NULL and has movement points left, you activate it, put it at the front 
of the TeamUnitList, Set bHolding to false and move along to as_NEXTUNIT, where this unit will be 
selected. 


else 
{ 


If the click was not within the selection window's rectangle, consider that a “cancellation” of the selection 
window, and pass the program along to GS_NEXTUNIT, where you can resume normal stuff. 


//outside of select window 
iGameState-GS NEXTUNIT; 
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} 
}break; 


T hat's about it for simple object selection. Wasn't that fun?T hese examples are getting longer and more 
complicated every time we do one. Н eck, with IsoH ех19 1, if you were to add a simple combat system, it 
would almost be a game! 


PIXEL-PERFECT OBJECT SELECTION 


Since | spent а great deal of time on simple object selection, | can only really give you an overview of 
pixel-perfect object selection and nudge you along the correct path to making it work. For turn-based 
strategy games, you can usually get away with simple object selection, but for real-time strategy games, you 
need pixel-perfect selection, or something close. 


Like many things in life, pixel-perfect object selection is simple for humans to understand but requires a 
great deal of work for computers to understand. T his is because of the human ability to think in the 
abstract, whereas a computer can only think in rigid terms. | use the word "think" here to mean “process 
information.’ W e are still some time away from having machines that actually “think” in a way that every- 
one agrees on. 


To start with, let's think about pixel-perfect object selection as human beings and then think about it the 
way a computer would. From the human perspective, we select a unit by clicking on it. As humans, this is 
easy to determine, because we see the units as separate from the background. A computer, however, knows 
no such distinction. As far as a computer is concerned, the display is just covered with a bunch of num- 
bers. It knows nothing of color or shape or units. It just sees (for example) the value OXFFFF (which to us 
appears to be pure white). As far as the computer is concerned, this number is meaningless. W hile we, as 
human beings, might be able to say “If you click here, this unit should be selected,” the computer has a 
much more involved process to make the same thing happen, since pixel colors are meaningless. H owever, 
the computer does have all the information necessary to determine whether or not you have clicked on а 
unit, or, at least, it can be given this information. 


As human beings, we can “eyeball” the display and see if we have clicked on a unit or not. T he computer, 
having no eyeballs (no, that webcam doesnt count), cannot do this. Т he closest thing to “eyeballing” that a 
computer has is bounding rectangles, as shown in Figure 19.3. By checking the mouse position against 
these rectangles, you can easily determine if the mouse is not over a unit, but the best result you can get is 
that the mouse might be on a unit, if it is within a bounding RECT. 
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Figure 19.3 


Bounding rectangles 


Well, something is better than nothing, so you'll take it. If you can eliminate some pixels as "not on а 
unit,” that just shortens your search. Computers do pretty well with deductive reasoning like this. 


N ext, if the mouse is over one of these bounding rectangles, you can determine where in the rectangle it is 
by subtracting the left and top of the вест from x and y. From here, you can get a pixel from the image 
containing the unit, which will be either the transparent color of the unit's tileset (in which case the mouse 
is not on the unit) or some other color (in which case the mouse is on the unit). 


l'm not actually suggesting you start poking around in the tileset image. Instead, right after loading it, you 
can create a two-dimensional array that is the same size as the unit's bounding Rect and fill it with true 
and false, depending on the pixel’s color. T hen, it's just a matter of going into this lookup table. U sing this 
method, you have to poke around the image only once (right after loading), and looking up values is then 
very quick. Of course, this solution isnt quite complete. Sure, you can tell whether or not the mouse is 
over a given unit, but the goal here is to select a single unit, and because of the isometric overlap, the 
mouse might be pointing to two units at once. 

If the mouse is over multiple units, logic dictates that you select the unit that is the southernmost (the far- 
thest down the display). T he easiest way to determine this (without poking around the tilemap structure 
and doing some lengthy tests and calculations) is to check the value of the unit's anchor point (specified in 
world coordinates). A higher y value wins. If the y values are the same, a higher x wins. 


MAKING IT HAPPEN 


l'm not going to do a full-fledged example on pixel-perfect object selection, but | will give you some code 
fragments that should put you on the right track. 
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CONSTRUCTING A LOOKUP TmHELE 


М uch of the information needed for pixel-perfect selection can be found in стітеѕе+ or calculated from 
it.T he anchor and the extent can be pulled directly out of the tileset for bounding box information. For a 
lookup table, you have to actually do some calculations and use some GDI. 


//this pointer will be allocated to contain the lookup table for a unit 
bool* bLookUp; 

int iWidth;//width of the lookup table 

int iHeight;//height of the lookup table 

//we are going to take the first unit (index 0) from tsUnit 

//get the width 
iWidth-tsUnit.GetTilelist()[0].rcSrc.right-tsUnit.GetTilelList()[0].rcSrc.left; 
//get the height 
iHeight-tsUnit.GetTilelist()[0].rcSrc.bottom-tsUnit.GetTilelList()LO].rcSrc.top; 
//allocate the lookup table 
b 
/ 


LookUp=new boolliHeight*iWidth]; 
/grab the dc from the tileset's image 
HDC hdc; 

tsUnit.GetDDS()->GetDC(&hdc) ; 

//grab the transparent color 

COLORREF crTrans-GetPixel(hdc,0,0); 
COLORREF crTest;//test pixel 

for(int y=0;y<iHeight;yt++) 

{ 


for(int x=0;x<iWidth;x++) 
{ 
crTest=GetPixel(hdc,tsUnit.GetTileList()[O].rcSrce.lefttx, 
tsUnit.GetTileList()[0].rcSrc.topty);//grab pixel 
if(crTest==crTrans)//test this pixel for transparency 
{ 


bLookUpL[x+y*iWidth]=false;//transparent pixel 


bLookUpLx+y*iWidth]=true;//non-transparent 


} 
//put the ас back 
tsUnit.GetDDS()->ReleaseDC(hdc); 
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T his is a simple scan conversion that copies the image into a monochrome bitmask. N ow, anytime you 
want to look up a value in this array, you can simply use bLookUpLx+y*iwidth]. If the value is true, the 
pixel is within the unit. If it's false, it isnt. T his code is good if you want to create just a single lookup 
table If you have more than one unit type (and it's pretty likely that you do), you'll want to have some 
sort of structure and make an array of that structure, like so: 


struct ObjectBitMask//structure to contain object bitmask 
{ 
bool* bLookUp; 
int iWidth; 
int iHeight; 
pS 
typedef ObjectBitMask* POBJECTBITMASK;//pointer type alias 


From here, creating an array of ObjectBitMasks and filling in that array is a simple matter of iterating 
through all the tiles and filling in the structures, 


CREATING A UNIT SELECTION LIST 


As | mentioned earlier, there are three steps to pixel-perfect object selection. First is the bounding box, sec- 
ond is the object's bitmask, which | just covered, and third is the objects anchor, in case you are hovering 
over more than one unit or object. T he most convenient thing to do is to make a struct that contains this 
information: 


struct UnitSelector//unit selection information struct 

{ 
RECT rcBound;//rectangle bounding the object (world coordinates) 
POINT ptAnchor;//anchor for the object (world coordinates) 
POBJECTBITMASK pobm;//pointer to a bitmask for the object 

| 

typedef UnitSelector* PUNITSELECTOR; 


For each object that can be selected in the world, you must fill in one of these structures. T his brings up 
the question, “W hich objects can be selected?" For the most part, you only want to fill out a structure for 
units that belong to the current player, and moreover, only units that are currently on-screen. Some games 
allow you to select enemy units so that you can see the status of that unit, but you cannot give it orders. 
Either way, you still only want those objects on-screen to be selectable (it shortens the search time). 


Before you get ahead of yourself, you must first know how to fill in this structure. 


UnitSelector UnitSel;//structure for our unit 
//pUnitInfo will be a pointer to a UNITINFO structure 
//similar to the one we've been using 

//first, copy the destination extent from the tileset 


OBJECT SELECTION 


CopyRect(&UnitSel.rcBound,tsUnit.GetTileList()[pUnitInfo-»iType].rcDstExt) ; 
//plot the world position of the unit 
UnitSel.ptAnchor-TilePlotter.PlotTile(pUnitInfo-»ptPosition); 

//assume that OBMList is an array of ObjectBitMasks 

//select the proper bitmask for the object 
UnitSel.pobm=&0BMListLpUnitInfo->iType]; 

//offset rcBound by the anchor 
OffsetRect(&UnitSel.rcBound,UnitSel.ptAnchor.x,UnitSel.ptAnchor.y); 


UnitSel now contains all the applicable information for a single object in the game. If you did this for all 
the units and objects in the game, perhaps storing them in a linked list, pixel-perfect selection would be 
within your grasp. 

typedef std::list<PUNITSELECTOR> UNITSELLIST;//unit selection list 

typedef std::list<PUNITSELECTOR>:: iterator UNITSELLISTITER;//iterator 


Н owever, you dont want to look through the entire list, just those objects that are on-screen or partially 
on-screen. You can keep а main list of Unitselectors that gets updated whenever a unit is moved, per- 

haps named MasterUnitSelList.T his lowers the overhead a little, because you don't have to completely 
fill in this list each frame. 


So, you can keep a separate list that you fill in each frame (or at least whenever the screen-space anchor 
changes or a unit moves), perhaps calling it ScreenUnitSelList.T hen all you need to do is fill it in. 


RECT rcClip;//this will be the rect we clip selectable units by 
RECT rcTest;//testing rect 
PUNITSELECTOR pUnitSel;//list item 
//copy the screenspace rect from the scroller 
CopyRect(&rcClip,Scroller.GetScreenSpace()); 

//translate the screenspace rect into world space 
OffsetRect(&rcClip,Scroller.GetAnchor()->x,Scroller.GetAnchor().y); 
//clear out the ScreenUnitSelList 

ScreenUnitSelList.clear(); 

//iterate through the master selectionlist 

for(UNITSELLISTITER 
iter=MasterUnitSelList.begin();iter!=MasterUnitSelList.end();iter++) 
{ 


pUnitSel=*iter;//grab item from list 

//find intersection 
IntersectRect(&rcTest,&rcClip,&pUnitSel ->rcBound) ; 
if(!IsRectEmpty(&rcTest))//if the intersection rect is non-empty... 
{ 
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ScreenUnitSelList.push_back(pUnitSel);// add unit to screen list 


T his isnt the optimal way to go about this, and you probably dont want to do this every frame, especially 
if you have a large number of units, but the preceding code is the main idea. N aturally, you'll want to opti- 
mize it so that fewer calculations need to be done. 


Finally, the actual selection can take place. You've got all the units and objects filtered into a smaller list. 
N ow you just have to see which units the mouse is over. 


//ptMouse is the mouse position (translated into world coordinates) 

POINT ptTemp;//temp testing point 

//the selected unit will be here, or NULL if none found 

PUNITSELECTOR pUnitSelFound=NULL; 

PUNITSELECTOR pUnitSelTemp;//temporary, for grabbing info out of list 

UNITSELLISTITER iter;//iterator 
h 
n 


//iterate through the screen list 
for(iter=ScreenUnitSelList.begin();iter!=ScreenUnitSelList.end();iter++) 


{ 


ptTemp=ptMouse;//copy mouse point 
pUnitSelTemp=*iter;//grab the item from list 
//phase one: check bounding rectangle 
if (PtInRect(&pUnitSel->rcBound, ptTemp) ) 
{ 
//point is within bounding rect 
//translate into rcBound coordinates 
ptTemp.x-=pUnitSel->rcBound. left; 
ptTemp.y-=pUnitSel->rcBound.top; 
//check the bitmask 
//phase two: check bitmask 
if (pUnitSelTemp->pobm->bLookUp[ptTemp. x+ 
ptTemp.y*pUnitSelTemp->pobm->iWidth]) 


//this is a "hit" 
if (pUnitSelFound==NULL ) 
{ 


//this is the first unit found 
pUnitSelFound=pUnitSelTemp; 


else 


//phase three: anchor position 
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//this is not the first unit found 
if (pUnitSelTemp->ptAnchor.y>pUnitSel Found->ptAnchor.y) 


//farther south 
else 


//not farther south 
if (pUnitSelTemp->ptAnchor. y==pUnitSel Found- 
>ptAnchor.y) 
{ 
//зате у 
if (pUnitSelTemp- 
>ptAnchor.x>pUnitSelFound->ptAnchor.x) 
{ 
//greater x 
pUnitSetFound-pUnitSetTemp; 


} 


T he bold lines mark the beginning of each of the stages of the algorithm so that you can more easily sep- 
arate them in your mind. T his is about all I’m going to say on the matter of pixel-perfect object selection. 
W hen you make your own object selection code, you should probably do the pixel-perfect stuff, because 
your users will expect it. 


MINIMAP, ZONES OF CONTROL, AND 
THE FOG OF WAR 


T here are a few elements common to most if not all isometric strategy games. Т hese are the minimap, 
zones of control, and the fog of war. N one of these are really very complicated or difficult to implement, 
but a discussion of isometric games is not complete without discussing these, since they are so prevalent. 


NYMNIMAPS 


A minimap is a smaller version of the games tilemap that lets a player get the big picture of the game as 
he is playing. All strategy games, whether real-time or turn-based, use the minimap. It has become a stan- 
dard feature, so not including it will hurt you. 


Since the minimap is just a smaller version of the етар, it is quite easy to implement. | usually have my 
minimap use tiles that аге 4x2 pixels in size In a 4x2 iso tile, the top four pixels are filled in with а color 
(usually all the same color and representing a full-sized tile), and the bottom four pixels are the transparent 
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color. For example, if you were making a minimap tile for an ocean, the top four pixels would be blue, but 
if you were making a minimap tile for a grassland, you would probably use a shade of green. 


A minimap usually is shown somewhere on-screen, typically in а corner, so it has its own screen space. T he 
minimap tiles, being only 4x2, calculate to a different world space, so in order to use a minimap, you need 
to make new copies of the isometric components that you will use only with the minimap. Н owever, you 
wont need all of the components— just theT ilePlotter, and maybe the scroller. 


T he idea is that the minimap is there primarily to show you the status of the entire playing area, but it is 
also a control that, if clicked, takes you to the area of the map that you clicked in the minimap. | think 
you've probably got a good understanding of the minimap and its role in games, so I'll just shut up now 
and get to the example. 


MINIMAP EXAMPLE 


Because you have decided that you want a minimap, you need someplace on-screen to put it. T his means 
you have to sacrifice some of the playing area. Typically, a minimap appears in the upper-right corner of 
the display, so that's where | decided to place it in 150Н ех19 2.срр, as you can see іп Figure 19.4. 


Figure 19.4 


Minimap example 


Окоекст SELECTION 


T he minimap code in this example is really just an add-on to the existing code base, so for easy separation, 
| placed it in a number of functions that take care of all the minimap stuff. Table 19.2 lists these func- 
tions, with a brief statement of their role in the example. 


Table 19.2 Minimap Functions 


Function Purpose 

SetupMiniMap Allocates and sets up the initial state of the minimap 
UpdateMiniMap Updates minimap information based on game information 
RedrawMiniMap Redraws the minimap 

ShowMiniMap Displays the minimap on-screen 

DestroyMiniMap Cleans up minimap information and deallocates structures 


T hese five functions take care of most of what you want to do with the minimap, but they are not by any 
means all-inclusive. Each of these functions is explained in detail in the following sections. 


SeETUrPMINIMAP 


Before | get to the actual code, | need to briefly discuss the new globals that were added because of the 
minimap. After all, this information has to be stored somewhere, right? Table 19.3 lists the new globals 
and describes their role in the application. 


Table 19.3 Minimap Globals 


Variable Purpose 

lpddsMiniMap O ff-screen surface on which the minimap's image is stored 
tsMiniMap Tileset used by the minimap to plot its mini-tiles 

MiniMap A pointer to an int, which is allocated to be the same size as 


the tilemap. Each map location then holds a number that is an 
index into the tsMiniMap tile list. 


MiniTilePlotter TilePlotter used by the minimap 


MiniScroller Scroller used by the minimap 
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W ith the preliminaries out of the way, you can finally get to the code First on the list is (naturally) 
SetupMiniMap, which does all your minimap initializations. 


void SetupMiniMap()//does initial setup of the minimap 
{ 
//create the surface 
lpddsMiniMap-LPDDS CreateOffscreen(1pdd,160,80); 
//Лоаа in the tileset 
tsMiniMap.Load(lpdd,"minimapts.bmp"); 


Before doing anything else, create a new surface 160 pixels wide and 80 pixels tall to contain the entire 
minimap. T his is hardcoded in the example but probably should not be. W hen you use a diamond map, as 
you are here, the calculations for width and height required by a minimap are as follows: 


MiniMapWidth=(MAPWIDTH+MAPHEIGHT )*TILEWIDTH/2; 
MiniMapHei ght=(MAPWIDTH+MAPHEIGHT )*TILEHEIGHT/2; 


In this example, MAPWIDTH and MAPHEIGHT are both 40, TILEWIDTH is 4, and TILEHEIGHT is 2. If you plug 
these numbers into the equations just shown, you'll get 160x80, which is what | got. О ther tilemap styles 
have different ways of figuring out the size of the minimap. It’s just based on the world space calculations. 


//initialize the minimap arrays 
МіпіМар=пем int[LMAPWIDTH*MAPHEIGHT]; 
for(int count=0;count<MAPWIDTH*MAPHEIGHT ;count++) 
{ 
MiniMap[count ]=0; 


N ext, you allocate the minimap array by allocating space for the global variable Minimap and initializing 
the array to all 05. 


//initialize iso components 
//tile plotter 
iniTilePlotter.SetMapType(ISOMAP DIAMOND); 
iniTilePlotter.SetTileSize(4,2); 
//scroller 
//calc worldspace 
iniScroller.CalcWorldSpace(&MiniTilePlotter, 
&tsMiniMap.GetTileList()[O].rcDstExt, MAPWIDTH, MAPHEIGHT); 
//set screen space 

RECT rcMiniScreenSpace; 
SetRect(&rcMiniScreenSpace,0,0,160,80); 
iniScroller.SetScreenSpace(&rcMiniScreenSpace) ; 
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//set the anchor 

POINT ptAnchor; 
ptAnchor.x=MiniScroller.GetWorldSpace()->left; 
ptAnchor.y=MiniScroller.GetWorldSpace()->top; 
MiniScroller.SetAnchor(&ptAnchor) ; 


Last, SetupMiniMap initializes the iso components used by the minimap. T his is pretty standard, and 
you've seen it before T he only weird part might be setting the anchor position. Since the entire minimap 
must be visible, the anchor is set to the world’s left and top. 


UPrPDATENININAP 


Because the tilenap changes throughout the game, so too does the minimap, since it is nothing more than 
a small reflection of the bigger picture. In this example, a given tile really has only three states. Either the 
map location is empty, or it contains units from one team or the other. Empty map locations show up 
green (tile 0 from tsMiniMap), and the blue and red teams each have their own tiles within tsMiniMap. 


void UpdateMiniMap()//updates the minimap array 

{ 
//update the minimap array to reflect game status 
for(int y=0;y<MAPHEIGHT;y++)//loop through rows 
{ 


for(int x=0;x<MAPWIDTH;x++)//loop through columns 
{ 
MiniMapLy*MAPWIDTH+x ]=0; 
//if empty, place a zero 
if(mlMap[x]Lyl.ulUnitList.empty()) 


MiniMapLy*MAPWIDTH+x ]=0; 


else 


//occupied by a player 
UNITLISTITER iteremIMap[x][yl.ulUnitList.begin(); 
PUNITINFO pUnitInfo-*iter; 
if(pUnitInfo!=pCurrentUnit || bFlash) 
MiniMapLy*MAPWIDTH+x J= 
1+pUnitInfo->iTeam; 
//put team info into minimap array 
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T his is pretty simple, really. You loop through all the map locations and check for emptiness (in which 
case you put a0 in the minimap array). If the location is not empty, place the appropriate colored tile in 
the array (with a special case if the unit being considered is the current unit, which must be made to 
blink). 


REDRAWNIINIMAP 


At some point, you will want to redraw the minimap. N aturally, you'll want to completely draw it during 
the beginning of the program, to give yourself a starting point. Later, as the map changes or as units move, 
you will want to redraw the minimap (or portions of it) to reflect changes in the game. 


T he RedrawMiniMap function does a complete redraw of the entire minimap. In areal game, you probably 
dont want to do this, especially if the map is very large. Instead, you might want to come up with a way of 
tracking changes on the minimap, and only redraw that which absolutely needs it. 


void RedrawMiniMap()//redraws the minimap to reflect current gamestate 
{ 
//redraw the entire minimap 
//in real code, you can keep two arrays 
//one valid this frame and one valid last frame 
//and then only blit the changes from last frame to this one 
//thus reducing the number of blits 
//clear out the minimap surface 
DDBLTFX ddbltfx; 
DDBLTFX ColorFill(&ddbltfx,0); 
lpddsMiniMap-»BIt(NULL,NULL,NULL,DDBLT WAIT | DDBLT COLORFILL,&ddbltfx):; 


T he first thing, naturally, is to clear out the minimap’s surface to black (or whatever your background color 
is). Do so if you intend to do a complete redraw, which is what I’m doing here. 


POINT ptPlot;//plotting point 
for(int y=0;y<MAPHEIGHT;y++)//loop through rows 
{ 
for(int x=0;x<MAPWIDTH;x++)//loop through columns 
{ 
//put the mini-tile 
ptPlot.x=x; 
ptPlot.y=y; 
//plot map position 
ptPlot=MiniTilePlotter.PlotTile(ptPlot); 
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//convert to screen coords 

ptPlot=MiniScroller.WorldToScreen(ptPlot); 

tsMiniMap.PutTile(lpddsMiniMap, 
ptPlot.x,ptPlot.y,MiniMapLy*MAPWIDTH*x]) ; 


№ ext, loop through the map tiles and plot the appropriate tile image from tsMiniMap. То plot the tile 
position, make use of MiniTilePlotter and MiniScroller, just like with a real isometric map. 


//show a rectangle around viewable area on minimap 

HDC hdc; 

lpddsMiniMap-»GetDC(&hdc);//borrow the dc from the minimap surface 
//get the anchor point from the main scroller 

POINT ptAnchor; 

ptAnchor.x=Scroller.GetAnchor()->x; 
ptAnchor.y=Scroller.GetAnchor()->y; 

//scale down by a factor of 16 (to go from a 64x32 tile to 4x2) 
ptAnchor.x/=16; 

ptAnchor.y/=16; 

//subtract the mini-scroller’s upper left 
ptAnchor.x-=MiniScroller.GetWorldSpace()->left; 
ptAnchor.y-=MiniScroller.GetWorldSpace()->top; 

//move to position in minimap 
oveToEx(hdc,ptAnchor.x,ptAnchor.y,NULL); 

//draw box, one line at a time 

LineTo(hdc, ptAnchor.x+30,ptAnchor.y);//30 is 480/16 
LineTo(hdc, ptAnchor.x+30,ptAnchor.y+30) ; 
LineTo(hdc,ptAnchor.x,ptAnchor.y+30); 
LineTo(hdc,ptAnchor.x,ptAnchor.y); 
lpddsMiniMap-»ReleaseDC(hdc);//restore the dc to the minimap 


T his final bit is lengthy but doesn't do anything spectacular. W hen using a minimap, you will no doubt 
want a rectangle bounding the area visible on-screen, since this gives your player a visible clue as to where 
in the world he is looking. М ost of the calculations convert world space coordinates into minimap pixel 
coordinates. Since your world uses 64х32 tiles, and the minimap only uses 4x2, you have to scale x and y 
down by a factor of 16. 
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SHOWMINIMAP 
T his is an easy one. You simply blit the minimap onto the back buffer. 


void ShowMiniMap()//shows the minimap on-screen 


{ 


ВЕСТ rcSrc;//src blitting rect 

RECT rcDst;//destination blitting rect 

//set src rect 

SetRect(&rcSrc,0,0,160,80); 

//set dest rect 

CopyRect(&rcDst,&rcSrc); 

OffsetRect(&rcDst,480,0); 

//do the blit 
lpddsBack-»Blt(&rcDst,lpddsMiniMap,&rcSrc,DDBLT WAIT,NULL) ; 


Likel said, not much to it. 


DESTROYNIININIAP 


As part of keeping the minimap separate from everything else in the program, | made a separate function 
to clean up the memory and tileset used by the minimap. 


void DestroyMiniMap()//cleans up the minimap 
{ 
//delete minimap array 
delete[] MiniMap; 
//destroy minimap surface 
if(lpddsMiniMap) 
{ 
lpddsMiniMap-»Release(); 
lpddsMiniMap-NULL; 
} 
//destroy minimap tileset 
tsMiniMap.Unload(); 


M ainly, this function does three things: it gets rid of the minimap array, it gets rid of the minimap surface, 
and it unloads the minimap tileset. 
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MINIMAP WRAP-UP 
I've only really scratched the surface of minimaps. T here are many ways to optimize what | ‘ve discussed 


here T he main point of this exercise is just to show you that a minimap is nothing more than a regular 
isometric map that has been reduced in size. 


ZONES OF CONTROL 


If you play any turn-based strategy games, whether on computer or with the old-style hex grids with the 
little pieces of cardboard to represent units, you are probably familiar with the concept of a zone of con- 
trol. О ther genres, like real-time strategy or R PGs, dont include this concept. | include this topic here 
mainly because it has to do with units, and | couldnt really come up with a better place for it. 


T here will be no example demonstrating zones of control, since it is relatively simple to implement. I’m 
just going to describe how to do it, show a few pictures demonstrating the concept, and leave it to you. 


Figure 19.5 shows some units and the zones of control they exert. A zone of control includes not only the 
square that the unit currently occupies, but also all neighboring squares, so determining which map loca- 
tions are occupied by a given player is pretty simple. 

Figure 19.5 


Zones of control 


THE PURPOSE OF ZONES OF CONTROL 

T he reason for zones of control goes way back into tabletop strategy game history. Т he idea is that a unit 
will not just control a single square, but can help regulate what goes on within one tile of that square. 

W hen | say “square,” | mean map location, since an isometric game has no squares! 
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T he main purpose of zones of control is to enable a player to get a tactical or strategic advantage with a 
rdatively small number of units. In order to understand how this can happen, you must first examine the 
rules of zones of control. 


ZONES OF CONTROL RULES 


You may move your own units in and out of any zone of control exerted by other units you control. T his 

can also be extended to include “friendly” units with whom you have a diplomatic alliance, and so оп.Т he 
rules for zones of control only apply to “hostile” units. H ostile units are any units that are not “friendly.” 

It’s sort of a circular definition, | know. 


Table 19.4 is a subset of possible "diplomatic" relationships that your team of units might have with 
other teams of units. It also describes whether units belonging to that team are considered friendly or 
hostile. Keep in mind that even though you might be at peace with another team, it doesn’t make their 
units friendly. 


Table 19.4 Diplomatic Situations and 
Unit Friendliness 


Relationship Unit Friendliness 
Self* Friendly 

Allied Friendly 

Peace Hostile 

W ar Hostile 


*You are always considered to be “allied” with yourself 


So, you ve established that zones of control are only taken into account with hostile units. Also, certain 
special units (such as diplomat and spy) might ignore zones of control entirely, and thus are not subject to 
the effects. T hese special types of units are usually called "stealth" units and are not typically detectable 
except by other stealth units. 


A unit may move into a hostile unit's zone of control. O nce within a zone of control, however, he cannot 
move from that tile onto another tile that is a zone of control. H e can move into a non-zone-of-control 
tile or he can attack, and that's about it. T his is to simulate how one unit will keep another unit "pinned 
down" and unable to maneuver in a location. 


W hile you lose some maneuverability when moving into a zone of control, the enemy unit is similarly 
constrained by your unit's zone of control and so is "pinned down" as well. O bviously, adding more units 
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on either side can completely trap or surround a unit, which will then be completely unable to do anything 
but attack and try to fight its way out. 


IMPLEMENTING ZONES OF CONTROL 


T here аге а couple of ways you might do this, but the simplest idea that occurs to me is to use some sort 
of bit flag within the map location structure. Each bit can mean a different team has a zone of control 
over that particular map location. If you dont like bit flags, an array of boo1s works just as well. Keeping 
it within the map structure is much better than calculating it on-the-fly, and is less prone to errors, plus 
you need to update the zones of control only when a unit is moved or killed. 


Нос or WAR 


T he fog of war is a feature much more widespread than the zones of control. M ost genres that typify iso- 
metric games have them, including turn-based strategy, real-time strategy, and RPGs. 


| lump two related ideas into the single concept of the fog of war. О ne idea is to mark which areas of the 
playing area you have explored, and the other is to mark which areas of the playing area you can actually 
see at a given point in time. 


U nits typically have what is called a sight radius, which differs in size depending on the unit. For example, a 
typical infantry unit might have a very small sight radius, but a unit on horseback will have a larger one. 


As a unit moves, different parts of the map become actively visible. By “actively visible” | mean that the 
unit can see any enemy activity happening within that area. O nce an area becomes actively visible, it is con- 
sidered “explored,” and explored areas do not disappear from the map once it is no longer actively visible 
(although when it is not actively visible no enemy activity is shown). Typically, an explored area that is not 
actively visible is darkened or grayed out. You can either supply a darkened version of each tile (this looks 
nice but requires alot of extra art) or supply a dithered (checkerboard) pattern of dark pixels to write over 
the top of the explored but not actively visible tiles. 


IMPLEMENTING A FOG OF WAR 


Putting together a fog of war is no great feat, once you've got the basics of isometric algorithms down— 
and you've already got the knowledge. It’s just a matter of putting the necessary information into the map 
structure and keeping that information up-to-date. T hen, you just have to modify the rendering function 
to blit it correctly. 


Keep in mind that the fog of war should affect not only the playing area, but also the minimap. I'm not 
doing a fog of war example for the simple reason that you can figure out how to do it on your own by 
now, I'm sure. 
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SUMMARY 


W eve explored quite a lot in this chapter— everything from object selection to minimaps and the fog of 
war. Some topics! explored in detail, and others | touched on only briefly. M y explanation of isometric 
algorithms is pretty much complete T he rest of the book is just refinements and applications of those 


algorithms. 
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ntil now, you've been learning about programming various components of an isometric engine— 

the plotter, the walker, the scroller, the M ouseM ap, and the renderer. You've learned about objects 
and units, and how to get them onto your tilemap. As the creator of isometric worlds, you need to know 
more than just these things to be effective. 


O ne of the most frequently asked questions | hear— through e-mail, on my message board, and in the chat 
room— is “H ow can | make isometric art?” M ost of the time | cannot answer this question in the small 
space given to me by e-mail or the message board, because the explanations require pictures to make them 
easy to understand. T he chat room you can completely write off, since very little can really be explained 

in that manner. So, this is my answer to all the people who have ever asked me about isometric art. M y 
techniques are neither all-inclusive nor exhaustive. T hey are the best I've come up with so far, and they 

are effective. 


H owever, this chapter is not just about art. | am a programmer first and foremost. M y artistic skills (in 
case you havent noticed) are somewhat lacking, and | have to fake it quite often. H owever, you can do 

some things with textures (you can find textures just about anywhere on theW eb) that will make them 
look like isometric art. 


Additionally, this chapter covers a few “how do they do that” kinds of algorithms that primarily have to 
do with isometric art— things like coastline, terrain fringes (including making the fog of war fuzzier), 
roads, rivers, and other connecting structures. Also, | have a few tricks up my sleeve to take a texture that 
is the wrong color and make it the right color. 


TILE RIPPING AND SLANTING 


| want to start with ripping and slanting. T hese are the two most fundamental tricks | use to convert a 
rectangular piece of art into an isometric Ше. Both give good-looking results. If you're stuck for terrain 
tiles, you can use these methods in a pinch to take a texture you found on theWeb and turn it into 
isometric tiles. 


TILE SLANTING 


| ve used tile slanting a number of times, mainly for board games, but this is not to say you couldnt 
use it in other situations. Figure 20.1 shows а snapshot of my game К night's C hallenge (you can find 

it on the CD in the Examples folder). Believe it or not, the entire chessboard was creating using a single 
16x16 square tile, but | rotated, slanted, and changed the color of the tile to make it look like more 
art was required than actually was. In other words, | used tile slanting to fake it, and it turned out 
looking awesome. 
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Knight's Challenge ЕЗ Figure 20.1 


| 
64 Knight's Challenge 


uses tile slanting 


Copyright 2000 Ernest $. Pazera 


So, how does tile slanting work? If you take a look at Figure 20.2, you will see the simple principle on 
which it is based. T ile slanting is just texture mapping— extrapolating the pixels within a different shape 
based on a texture and the vertices of another polygon. 


Figure 20.2 
Texture mapping 


Later, when you get into Direct3D, DirectX will take care of texture mapping for you. U nfortunately 
youre still in 2D land, so you have to do it yourself. Dont worry, though. You wont be required to do any 
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really complicated math, because changing a square into a diamond is a lot easier than changing it into 
a different arbitrary shape. 


And now, heres the big trick: when tile slanting, you simply treat the isometric tile as if it were a diamond 
map, and just use really small tiles (4x2 pixels in size, with the bottom pixel row empty), using the rectan- 
gular art as a "tilemap" that contains the colors that belong on the diamond map. 


For а 64x32 isometric tile (which is my standard), you need a 16x16 square image. From there, you 
can slant it to look like it was drawn isometrically. 


CAUTION 


I’ve only really gotten tile slanting to work for isometric tiles that have 
an aspect ration of 2:1 (the width is 2 times the height). If you are 
working with other sizes and shapes, texture mapping becomes more 
complicated. 


lve been throwing numbers at you here without really explaining their basis. | plan to rectify that 
situation now. 
Figure 20.3 shows a zoomed-in version of the tile shape! have been using throughout this book. It is no 


accident that | use this tile shape (and very similar shapes with an aspect ration of 2:1).T his shape is by 
far the easiest to work with, and it looks good. 


Figure 20.3 


Standard iso tile shape, 
severely magnified 
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N otice that there are four dark boxes around the topmost pixels of the tile. Also, next to and one row 
down on either side are two more dark boxes. T his is to show you how the tile shape is being converted 
into a diamond map, to give a basis for all these numbers | ve been spouting. 


So, the first row of the image has 4 pixels, located at positions (30,0) through (33,0). T he next row adds 
2 to either side, giving 8 pixels from (28,1) through (35,1). T his trend continues until row 16, which 
extends the width of the image, from (0,15) to (63,15). After that, the number of pixels per row is 
reduced on each side by 2, until at row 31 there are again only 4 pixels, from (30,30) to (33,30). Row 32 
is empty. l'Il repeat that: row 32 is empty. In all of the 2:1 ratio tiles, the last row is empty. T his will be 
important in a minute. 


N ow, say that the top pixel row contains map location (0,0) of a diamond map. T here are 4 pixels, so use 
a 2:1 ratio tile that is 4 pixels wide, making a 4x2 tile. T he first row of this "micro-tile" is filled with 4 
pixels. T he second row, which is the last row, is empty. See? | told you that would be important. 


T he second row has 8 pixels, which can fit two micro-tiles, which, handily enough, will be map locations 
(0,1) and (1,0) in the diamond map. See how this is shaping up?Y ou keep progressing this way down the 
map until row 16, which has all 64 pixels set. Dividing by 4, you get 16 micro-tiles across the image, so 
the diagonal of the square image needs to have 16 pixels, which means you need a 16x16 square image in 
order to make this work. 


То make a more general statement, if you want to break up a 2:1 iso tile into 4x2 micro-tiles, you divide 
the width by 4 and use that for the width and height of the square source image. H owever, you might not 
have a 16x16 image. Instead, you might have a 64x64 or 128x128 or even 256x256 image (these three 
are by far the most common texture sizes). N o problem. Simply divide the image into little 16x16 
squares, and slant each one of them. N aturally, you probably want to keep track of which one is which so 
that you can use the images together without having them look strange. 


TILE SLANTING EXAMPLE 


Enough talk about tile slanting. Let's go ahead and do it, programmatically. Load 150Н ex20_ 1.срр.Т his 
example is kind of a throwback to Part |, because it operates within a window instead of full-screen, and it 
doesnt use any of the isometric components you've developed since then. 


T he program works by loading a square texture into а CaDI Canvas (gdicSquare) and creating a larger 
GDI canvas to contain the isometric image (о41с150). It isloaded during Prog_Init.T he isometric tile 
is created with the following code: 


//loop through x texture coords 
for(tx=0;tx<16;txt++) 
{ 
//\oop through y texture coords 
for(ty=0;ty<16;ty++) 
{ 
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//grab the color from the texture 
crColor=GetPixel (gdicSquare,tx,ty); 
//calculate x and y 

х=30+1х*2-1у*2; 

у=їх+їу; 

//1оор through four pixel positions 
for(tempx=x;tempx<(x+4) ;tempx++) 

{ 


SetPixelV(gdicIso,tempx,y,crColor); 
//set color on iso picture 


} 


T his code is all hardcoded, and it will only work to convert a 16x16 square image into a 64x32 isometric 
image. If you have a different size, though, this method is easily adjusted to accommodate it, as long as 
the iso tile has a ratio of 2:1. 


T here isnt much to the operation of this program. It loads the image and shows the isometric tile 
repeated, as it would be on a tilemap. Pressing 2 takes you to a view of а map of the square tile Pressing 


1 takes you back to the isometric view. Figure 20.4 shows the isometric view, and Figure 20.5 shows 
the square view. 


Figure 20.4 


ІѕоН ех20 1.срр in the 
isometric (default) view 
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ші IsoHex 20-1 Figure 20.5 


IsoHex20 1.cpp in 
the square view 


Before you move on, | want to give you the generic code that will work with any 2:1 ratio isometric tile: 


//WIDTH is the width of an isometric tile. This must be a multiple of 4. 
//HEIGHT is the height of an isometric tile. This must be WIDTH/2. 
//TEXTURESIZE is the width and height of the texture. It will be WIDTH/4. 
//loop through x texture coords 

for(tx=0; tx<TEXTURESIZE; Ех++) 

{ 


//\oop through y texture coords 
for(ty=0;ty<TEXTURESIZE;ty++) 
{ 
//grab the color from the texture 
crColor=GetPixel(gdicSquare,tx,ty); 
//calculate x and y 
X=WIDTH/2-2+tx*2-ty*2;//see below 
y=txtty; 
//loop through four pixel positions 
for(tempx=x;tempx<(x+4) ; tempx++) 
{ 


SetPixelV(gdicIso,tempx,y,crColor); 
//set color on iso picture 
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Of the preceding lines of code, one in particular merits some extra discussion: x=wIDTH/2-2+tx*2-ty*2. 
T he tx*2-ty*2 is easily explained, because this is the standard calculation for a diamond map, but where 
does the wIDTH/2-2 come from? W dl, since a diamond map's (0,0) lies at the topmost map location, you 
must have some way of centering, so you add итотниг.Т he -2 part comes in because the micro-tile you 

are putting onto the image is 4 pixels wide and also must be centered. H ope this clears up any confusion. 


COLOR-BLENDED TILE SLANTING 

T ile slanting looks pretty cool, and it can be used to generate decent looking images from square 
textures. H owever, the isometric images generated in this manner look a bit more coarse than the 
square textures from which they were generated. T his is a natural result of a pixel’s being expanded 
into a string of 4 pixels. 

To minimizethis look, you can either not usetile slanting at all, or you can find a way to smooth out 
the isometric image T he way I'm about to show you is using color blending. 

Consider Figure 20.6 for a moment. It’s a graphical, zoomed-in schematic of how tile slanting works. 
Admittedly, it uses a very small 3x3 texture, but the principle is the same T he three highlighted pixels 
in the texture are stretched to become the highlighted squares in the isometric image. 


Figure 20.6 


Tile slanting 
(a zoomed-in view) 


№ ow, say you want to make the transition from one 4-ріхе! micro-tile to another less abrupt. You could 
put an "in between" color on each of the ends and the main color in the middle two pixels. T his would 
give you something that resembles Figure 20.7. As you can see, the color transitions are smoothed out 
somewhat for an overall better-looking tile. 
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Figure 20.7 


Tile slanting with 
color blending 


T his color blending is done with just a modification of the scanning loop in IsoH ех20 1.срр. In fact, 
ISOH ех20 2.срр has the exact modification you need. It's all just a matter of grabbing the diagonal neigh- 
bors and using them to calculate the appropriate colors. 


W hether or not you color blend with your tile slanting is totally up to you. I'm just here to present the 
information and give you choices. 


TILE RIPPING 


| like tile ripping. It can make a boring tilenap into an interesting one, because you can texturize a map 
with a texture that is larger than a single tile, and the texture can be a rectangular piece of art. [п addition, 
you can get some interesting effects from modulating a textured isometric tile onto another texture. l'Il 
cover modulation and what it's all about in a moment. 


T he first thing you need, of course, is a texture (see Figure 20.8). T he texture should be repeating, mean- 
ing that when a copy of the texture is put next to another copy, there should be no seam. If you do havea 
texture with a seam, there are а few methods you can use to make it seamless. l'Il get to those methods 
soon, too. 
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Figure 20.8 


A texture 


T he size of the texture is pretty important. T he width has to be a multiple of your iso tile width, and the 
height has to be a multiple of the iso tile height. Since you are using 64x32 tiles, this wont be a problem, 
because most textures are 128x128 or 256x256. If you are using a different tile size or an irregular tex- 
ture, you might need to stretch or squash the texture. 


MAKING A REPEATING TEXTURE OUT OF A 
NONREPEATING TEXTURE 


You don't have to worry about the texture! chose for illustration. It repeats seamlessly, as shown in 
Figure 20.9. H owever, many of the textures you'll find (there are a lot of them on theW eb) dont quite 
repeat. T һеуге supposed to, but theres usually some sort of seam visible, despite the texture creator's 
attempts to hide it. 
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Figure 20.9 


A repeating texture 


NOTE 

By the way, if you can’t make textures yourself, be sure to 
get on the Web, go to your favorite search engine, and type 
textures. You will find more textures than you'll ever 


need. Also, because I'll show you how to modulate to 
change the color, it doesn't matter if the color of the tex- 
ture doesn't quite match, because you can make it match. 


Figure 20.10 shows a texture | found on theW ё. It is a repeating texture, but there is a problem with 
using it for my 64x32 tiles. T his texture is 170x170, and neither 64 nor 32 divides evenly into 170. 
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Figure 20.10 


Texture 170x170 
| found on the Web 


So, | have a few choices. | can shrink it to 128х128, expand it to 192х192, or crop it to 128x128. 
Because cropping to 128x128 gives me a nonrepeating texture, I'll do that, just to illustrate how you 
can get a repeating texture out of a nonrepeating one. 


Figures 20.11 through 20.13 show the process of cropping to 128x128, checking for the repeat, and 
zooming in on the seams. Figure 20.12 demonstrates that even after being cropped to 128x128, the 
texture still looks pretty good, and the seam is hardly noticeable. Still, if you zoom in, as shown in 
Figure 20.13, the seam is indeed there. 


Figure 20.11 


The texture cropped 
to 128x128 
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Figure 20.12 
Checking for the repeat 


Figure 20.13 
Zooming in 
on the seams 


Н onestly, this texture can be used without any more work, and that is a credit to the textures designer. 
Still, I'm trying to demonstrate making seamless tiles, so that is what you're going to do! 


Basically, you make a nonrepeating texture into a repeating one by using the texture four times and 
flipping some of the copies horizontally or vertically, or both. You first make an image that is twice the 
width and twice the height of the original texture T hen you place the texture (flipped as needed) in 
each of the four corners. 


ББА | ISOMETRIC GAME PROGRAMMING WITH, DIRECTX 7,0 


In the upper-left corner, do no flipping at all. In the upper-right corner, do a horizontal flip. In the lower- 
left corner, do a vertical flip, and in thelower-right corner, do a horizontal flip and a vertical flip. T his gets 
rid of the seam but adds a sort of "reflected" pattern to the texture, as shown in Figure 20.14. Also, the 
texture is now four times larger, so you have to take that into consideration. 


Figure 20.14 
Making it seamless 


Basically, this is а game of deciding what looks good. You often have to play with a texture, stretching, flip- 
ping, rotating, and applying filters until you find what looks good to you.T here is no one set method. 


GETTING TILES OUT OF A TEXTURE 


So, you either found yourself a repeating texture of the appropriate size, or you played with a texture until 
it was satisfactory in size and repeated. Great! N ow what? 


N ow it's just a matter of getting all the tiles out of it. In order to do that, you need your basic tile shape, 
which you've got, and the вест extent that will be used for your tiles, which you also have or can deter- 
mine very easily. You need one other thing: aT ilePlotter. 


T he basic steps for tile plotting are as follows: 


1. Make a larger image, and place the texture on it four times in a 252 pattern. 
D etermine the number of tiles you need to fully rip this texture. 

Loop through the tiles that need ripping. 

Plot the tiles. 

Rectify the tiles to be within the texture. 
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6. Copy the rectangular portion of the texture onto а new image. 
7. Apply the isometric shape using modulation. 


| Know at this point the process sounds like a bunch of mumbo jumbo. All in due time. 


STer 1: TILE THE TEXTURE ZXZ 


Because of the nature of isometric tiles (the overlapping), you will have some tiles that will be on the edge 
of the texture If you didnt tile your texture, you would have partially empty tiles, which is not good. 


STerP E: DETERMINE THE NUMBER OF TILES 


T he number of tiles you need depends on texture width and height and tile width and height. Divide 
texture width by tile width and texture height by tile height. M ultiply these two numbers, then multiply 
the result by 2, and that's the number of tiles. 


If you're interested in the basis, here goes: Imagine that you have a 128x128 texture and are using 64x32 
tiles. An example of tile ripping for these parameters is shown in Figure 20.15. T һе tiles in this figure look 
the most like a staggered map, so you'll deal with this as though it were a staggered map for the time being. 


Figure 20.15 
Example of tile ripping 
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T here аге two columns of tiles and eight rows. Columnsz rexturewidth/ TileWidth. 128/ 64-2. 


Rows are based on texture height, but you have to take into account the overlap between rows, and 
multiply by 2. Rows=2*TextureHeight/ TileHeight. 2*128/ 32-8. 


Take the number of rows times the number of columns, and that's the number of tiles. 2*8 = 16. 


STEP <: LOOP THROUGH THE TILES 


T his is pretty easy. You loop X from 0 to Columns- 1, and you loop Y from 0 to Rows- 1. It's important 
to note here that you can use any sort of tileplotting, and use the same loop, and it will come out fine no 
matter what. O ne warning, though: be sure to use the same sort of tileplotting when ripping tiles as you 
do when placing tiles. O therwise, putting the tiles back together again is a pain. 


//calculate columns and rows 

int Columns=TEXTUREWIDTH/TILEWIDTH; 
int Rows=2*TEXTUREHEIGHT/TILEHEIGHT ; 
// loop through columns 
for(int x=0;x<Columns;x++) 


{ 


//loop through rows 
for(int у=0;у<Вомѕ ; у++) 
{ 
//we’11 do some plotting and ripping here 


STer H: FLOT THE TILES 


You can already do this step. Use cTilePlotter, or your own function, or even just a few quicky 
formulas— whichever makes you happy. T he following code does a standard plot for a diamond-shaped 
tilemap. (T his code would go within the column and row loops). 


//standard diamond-map plot 
plotx=(x-y)*TILEWIDTH/2; 
ploty=(x+y )*TILEHEIGHT/2; 


ПТЕР Б: RECTIFY THE TILES 
In this case, retify means to validate, or to take a value and bring it into an acceptable range. 


T he variables р1о%х and ploty describe the upper-left corner of the rectangular region from which your 
tile will be ripped. In order for tile ripping to work, p1otx and ploty have to be within the upper-left 
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quadrant of the 2x2 tiled texture T his guarantees that you will have a full 64x32 image from this portion 
of the texture 


So, in order to ge рто+х and ploty where they need to be, simply take the modulus (2) with 
TEXTUREWIDTH and TEXTUREHEIGHT, and check for negatives. 


//find remainder 

plotx4=TEXTUREWIDTH; 
plotyZ-TEXTUREHEIGHT:; 
//check for negatives 
if(plotx«0) plotx--TEXTUREWIDTH; 
if(ploty«0) plotyt+=TEXTUREHEIGHT ; 


N ow plotx and ploty are within the acceptable range, and you can continue. 


STer Еш Кат THE RECTANGULAR AREA ТО TILE 


N ow you plot the part of the textured image from (plotx,ploty) -(plotx+TILEWIDTH, ploty+TILE- 
HEIGHT) to wherever you are storing the tile image, whether that be an НОС somewhere, а D irectD raw 
surface, or elsewhere. |'m not putting any code in right now, since rendering is rather API-specific. I'm just 
trying to ge the algorithm across. 


STerP 7s MODULATE WITH THE TILE SHAPE 


Again with the word “modulate?” M odulate just means to multiply, although it's a different sort of multipli- 
cation, because you are multiplying colors. Essentially, this step can be accomplished with an all-white tile 
shape and blitting with $всАМО. Officially, however, | have to say "modulate" because you can use tile 
shapes that dont necessarily consist of all-white pixels to do neat tricks. 


So, there it is— seven steps to tile ripping. I'm pretty sure, however, that you would like some sort of 
example to make the concept more concrete. | know | would, so let's do that. 


TILE RIPPING EXAMPLE 


Go ahead and load ир IsoH ех20 3.cpp, our tile ripping example du jour. Like IsoH ех20 1, this is a very 
simple application that doesn't use any fancy isometric components, because they are not needed. 


T he following code is all that is needed to rip a rectangular texture into small isometric bits. It should be 
easy enough to follow. 


//load texture canvas 
gdicTexture.Load(NULL, *texture. ртр”); 
//load iso shape 
gdicIsoShape.Load(NULL, ”’IsoShape. bmp”) ; 
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quadrant of the 2x2 tiled texture T his guarantees that you will have a full 64x32 image from this portion 
of the texture 


So, in order to ge рто+х and ploty where they need to be, simply take the modulus (2) with 
TEXTUREWIDTH and TEXTUREHEIGHT, and check for negatives. 


//find remainder 

plotx4=TEXTUREWIDTH; 
plotyZ-TEXTUREHEIGHT:; 
//check for negatives 
if(plotx«0) plotx--TEXTUREWIDTH; 
if(ploty«0) plotyt+=TEXTUREHEIGHT ; 


N ow plotx and ploty are within the acceptable range, and you can continue. 
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N ow you plot the part of the textured image from (plotx,ploty) -(plotx+TILEWIDTH, ploty+TILE- 
HEIGHT) to wherever you are storing the tile image, whether that be an НОС somewhere, а D irectD raw 
surface, or elsewhere. |'m not putting any code in right now, since rendering is rather API-specific. I'm just 
trying to ge the algorithm across. 


STerP 7s MODULATE WITH THE TILE SHAPE 


Again with the word “modulate?” M odulate just means to multiply, although it's a different sort of multipli- 
cation, because you are multiplying colors. Essentially, this step can be accomplished with an all-white tile 
shape and blitting with $всАМО. Officially, however, | have to say "modulate" because you can use tile 
shapes that dont necessarily consist of all-white pixels to do neat tricks. 


So, there it is— seven steps to tile ripping. I'm pretty sure, however, that you would like some sort of 
example to make the concept more concrete. | know | would, so let's do that. 


TILE RIPPING EXAMPLE 


Go ahead and load ир IsoH ех20 3.cpp, our tile ripping example du jour. Like IsoH ех20 1, this is a very 
simple application that doesn't use any fancy isometric components, because they are not needed. 


T he following code is all that is needed to rip a rectangular texture into small isometric bits. It should be 
easy enough to follow. 


//load texture canvas 
gdicTexture.Load(NULL, *texture. ртр”); 
//load iso shape 
gdicIsoShape.Load(NULL, "IsoShape.bmp"); 
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First (of course), you have to load in the two images you are using— the texture and the isometric shape. 
It’s pretty cool, really, that only these two are necessary, and the rest can be generated programmatically. 
In real-world situations, you'd want to prepare the textured tiles [оге distributing the game. 


//grab dc from main window 

HDC hdc=GetDC(hWndMain); 

//calculate rows and columns of tiles 
iColumnsegdicTexture.GetWidth()/gdicIsoShape.GetWidth(); 
iRows-2*gdicTexture.GetHeight()/gdicIsoShape.GetHeight(); 

//create tiled texture canvas 
gdicSource.CreateBlank(hdc,gdicTexture.GetWidth()*2,gdicTexture.GetHeight()*2); 
//create tile canvas 
gdicTiles.CreateBlank(hdc,gdiclIsoShape.GetWidth()*iColumns,gdicIsoShape.GetHeight 
()*iRows); 

//restore dc to main window 

ReleaseDC(hWndMain,hdc); 


Second, you need a few extra surfaces to work from, the 2x2 texture tiled image, and an image large 
enough to accommodate all the ripped tiles (which is why the columns and rows are calculated). 


//create tiled texture image 

//upper left 
BitBlt(gdicSource,0,0,gdicTexture.GetWidth(),gdicTexture.GetWidth(),gdicTexture,O 
‚О, SRCCOPY) ; 

//upper right 
BitBlt(gdicSource,gdicTexture.GetWidth(),0,gdicTexture.GetWidth(),gdicTexture.Get 
idth(),gdicTexture,0,0,SRCCOPY); 
//Томег left 
BitBlt(gdicSource,0,gdicTexture.GetHeight(),gdicTexture.GetWidth(),gdicTexture.Ge 
tWidth(),gdicTexture,0,0,SRCCOPY); 
//lower right 
BitBlt(gdicSource,gdicTexture.GetWidth(),gdicTexture.GetHeight(),gdicTexture.GetW 
idth(),gdicTexture.GetWidth(),gdicTexture,0,0,SRCCOPY); 


м 


№ ext, you need to fill the source image (the 2x2 tiled texture image) with the image data from the 
textures. T here are four blits, one for each corner. 


//rip out the tiles 
int x; 

int y; 

int plotx; 

int ploty; 

//loop through columns 
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for(x=0;x<iColumns;x++) 


{ 

//loop through rows 
Ғог (у=0; у<1 Rows 
{ 


;у++) 


//determine plotx апа ploty 

plotx=x*gdicIsoShape.GetWidth( )+(y&l)*gdicIsoShape.GetWidth()/2; 
ploty=y*gdicIsoShape.GetHeight()/2; 

//bring plotx and ploty within appropriate range 
plotxz-gdicTexture.GetWidth(); 

ploty%=gdicTexture.GetHeight(); 

//check for negatives 

if(plotx«0) plotx+=gdicTexture.GetWidth(); 

if(ploty«0) plotyt=gdicTexture.GetHeight(); 

//grab this part of the source surface, and place it on the tile 


surface 


BitBlt(gdicTiles,x*adi 
gd 
gd 

//modula 


BitBlt(gdicTiles,x*gdi 
gd 
gd 


cIsoShape.GetWidth(),y*gdicIsoShape.GetHeight(), 
iclsoShape.GetWidth(),gdiclIsoShape.GetHeight(), 
icSource,plotx,ploty,SRCCOPY); 

te with the iso shape 


cIsoShape.GetWidth(),y*gdicIsoShape.GetHeight(), 
icIsoShape.GetWidth(),gdiclIsoShape.GetHeight(), 
icIsoShape,0,0, SRCAND) ; 


Finally, rip the tiles, and modulate the image data with the isometric shape. T hat's really all there is to it. 
T hen, all you have to do is make use of the tiles you have created, as demonstrated in snowMap. 


void ShowMap(HDC hdc)//show sample map 


{ 
//vars 
int x; 
int y; 
int tilex; 
int tiley; 
int plotx; 
int ploty; 
//clear out ас 
RECT rcFill; 


1S0METRIC GAME PROGRAMMING ulrH DIRECTX 7,0 


GetClientRect(hWndMain,&rcFill); 

//fill rect 

FillRect(hdc,&rcFill,CHBRUSH) GetStockObject(BLACK BRUSH)); 
//loops 

for(x=0;x<10;x++) 

{ 


Ғог(у=0;у<20;у++) 
{ 

//calculate plotted positions 
plotx=x*gdicIsoShape.GetWidth()+ 
(y&l)*gdicIsoShape.GetWidth()/2; 
ploty=y*gdicIsoShape.GetHeight()/2; 

//calculate which tile to use 

tilex=(x%iColumns )*gdiclsoShape.GetWidth(); 
tiley=(y%i Rows )*gdiclsoShape.GetHeight(); 
//blit the tile 
BitBlt(hdc,plotx,ploty,gdiclsoShape.GetWidth(), 
gdicIsoShape.GetHeight(),gdicTiles,tilex,tiley, 
SRCPAINT); 


T his is pretty basic, with perhaps one exception— the calculation of ti lex and tiley.T hese numbers аге 
based оп the x and у (in a more complex app, they would be тарх, тару). Т he reason is that you need to 
keep the texture looking right, and any given tile has to have a certain piece of the texture or else the image 
wont look right. Luckily, you can just find the remainder of x/column and y/row to find out which one 


EXTRA GRAPHICAL OPERATIONS 


| promised Г discuss two very common graphical operations and how you can do them programmatically. 
T hese are gaysaling— taking an image and converting it to an image with 256 shades of gray in it and 
modulating which you can use to modify an images colors). You can combine these two operations to 
change textures to something more to your liking. 


GRAYSCHALING 


T he act of grayscaling is pretty simple and straightforward. Y ou take the red, green, and blue components 
and combine them, making a single gray component for the image. 
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Usually, the RGB components are weighted percentage wise. Т he human eye is most sensitive to green, 
50 that usually gets the highest percentage weight. T he eye is least sensitive to blue, which gets the lowest 
weight. Red gets whatever is left over. A very good weighting scheme is 30% for red, 59% for green, 
and 11% for blue. 


T he following is an example of grayscaling an image that has been loaded onto an H DC: 


//hdc is the dc of the image 
//WIDTH is the width of the image 
//HEIGHT is the height of the image 
int iRed,iGreen,iBlue,iCombine; 
COLORREF crColor; 

//loop through rows 

for(int y=0;y<HEIGHT; у++) 

{ 


//loop through columns 

for(int x=0;x<WIDTH;x++) 

{ 
//grab the pixel 
crColor=GetPixel(hdc,x,y); 
//extract the RGB components 
//and multiply by percentage 
iRed=GetRValue(crColor)*30; 
iGreen=GetGValue(crColor)*59; 
iBlue-GetBValue(crColor)*11; 
//combine the rgb 
1Сотріпе=( 1 Кед+1 бгееп+1В1ие ) /100; 
//reform into а gray image based on iCombine 
crColor=RGB(iCombine, iCombine,iCombine) ; 
//replace the pixel 
SetPixelV(hdc,x,y,crColor); 


As you can see, grayscaling is pretty easy. You can also change the percentage weights (always make sure 
they add up to 100) to get some different effects. T he effects won't be drastically different, but the 
appearance will change. 


MYIODULATION 


M odulation is the act of multiplying colored images to get new colored images. It can be used 
for a variety of effects; one of these effects is changing a textures color after it has been grayscaled. 
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For example, you might find a texture that you really like, but it’s the wrong color; maybe it’s purple when 
you want it to be green. N o problem. First, grayscale the image, and then modulate it with the color of 
green that you want, and blammo, you've instantly changed the color of the texture while retaining its 
detail and the proper variations in tone 


T hat just leaves you with the question of how to multiply a color by another color. Actually, you dont 
multiply the colors by one another. Instead, each color's components get multiplied by another color's 
components. R ed multiplies with red, green with green, and blue with blue. H owever, multiplying colors in 
their current form (from 0 to 255) cant work, because the final result must also be within that range. So 
you have to make the components equal a value from 0.0 to 1.0, with 0 being 0.0 and 255 being 10.To 
convert from the 0-to-255 to the 0.0-to- 1.0 format, you need only convert to floating-point and divide by 
255. So, the following formulae will work for modulating color components: 


RC/255-R1/255*R2/255 
GC/255=G1/255*G2/255 
BC/255=B1/255*B2/255 


R 1,G1,B1 and R2,G2,B2 represent the two source colors, and RC,GC,BC is the combined color. 
№ aturally, you'd like а more simplified version of the formula, with RC,GC, and BC alone on the left 
side so that you can use them in a program. H ere they are: 


RC=R1*R2/255; 
GC=G1*G2/255; 
BC=B1*B2/255; 


And there you have it. You can use these lines as-is in a program. М ow let's modulate. 


//hdcl and hdc2 are source images; hdc3 is the combined 
//WIDTH is width of images; HEIGHT is height of images 
//all three images are the same dimensions 

int rl,gl,bl;//source color 1 

int r2,92,b2;//source color 2 

int r3,93,b3;//destination color 

COLORREF crColorl;//source 1 

COLORREF crColor2;//source 2 

COLORREF crColor3;//dest 

//\oop through rows 

for(int y=0;y<HEIGHT; y++) 

{ 


//loop through columns 

for(int x=0;x<WIDTH;x++) 

{ 
//grab pixels 
crColorl=GetPixel(hdcl,x,y); 
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crColor2-GetPixel(hdc2,x,y); 
//extract components 
rl-GetRValue(crColor1); 
gl=GetGValue(crColorl); 
bl=GetBValue(crColorl); 
r2=GetRValue(crColor2); 
g2=GetGValue(crColor2); 
b2=GetBValue(crColor2); 
//multiply components 
r3-rl*r2/255; 

43-41%42/255; 

b3=b1*b2/255; 

//combine components 
crColor3=RGB(r3,93,b3); 
//set pixel 
SetPixelV(hdc3,x,y,crColor3); 


And that's modulation. If you want to combine portions of an image with one color and other portions 
with another color, just make a two-colored image and modulate. M odulation can also be used to make 
light maps, shadow maps, and a variety of other effects. Play around with it and see what you can create. 


SUMMARY 


Compared to other chapters, this one was a little short, and not nearly as technologically sophisticated. 
Art, in general, tends not to ре 50. Still, looking good is а part of making a game, and it never hurts to 
have a few tricks up your sleeve (especially if you cant draw very wall, like me). 
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FRINGES AND INTERCONNECTING STRUCTURES 


had a hard time deciding where to put this chapter. It seemed to belong in several places, and at the 
same time there was really no perfect place for it. So | tacked it onto the end of Part II, because it was 
just too important to put into an appendix. 


T his chapter is concerned with a few topics, mostly dealing with isometric art and how to handle it. | 
focus on two major areas: fringes and interconnecting structures. By frings, | mean transitions from one 
sort of terrain to another, like from grassland to plains, but also including coastline (coastline being just a 
transition from land to ocean). By interconnecting srudures | mean roads, railroads, rivers, forests, hills, moun- 
tains, walls, and so on. 


As you can see, these issues are important both to the artist designing the isometric tiles and objects and 
to the programmer, who has to make use of the art. T he main idea is that you want to make the art as 
easy to generate as possible, and you want to геу on as few images as possible, thus conserving valuable 
display memory. Н owever, you still want good performance, so you want to reduce the number of blits 
necessary to get a tile onto the screen. T his is the eternal juggling act that you as a graphics programmer 
have to face every day. 


FRINGES 


Fringes can be used for several things, the most obvious being coastline, but they can also work for transi- 
tions from one terrain to another, or the edge of a fog of war. 


T he first question out of your mouth will be “W hy use fringes?” Figures 21.1 and 21.2 provide a good 
example of why.T his is an old isometric sample program | wrote about a year or so before | started this 
book. You can find it and the source for it on the CD. In this program, | set out to demonstrate a very 
simple coastline effect. Figure 21.1 has the coastline effect turned off, and Figure 21.2 has the coastline 
effect on. № aturally, the coastline on makes a better-looking picture. So, in answer to your question, you 
should use fringes because they enhance a дате appearance. 
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Bii Isometric Example #3 


Figure 21.1 
No fringe makes 
for unrealistic- 
looking games 


E Isometric Example #3 


Figure 21.2 
| 
à A fringe smoothes 
things out 


Just to hammer home the point, | ve included Figure 21.3, which | believe looks very good, even though it 
is very simple. (T he graphics were tile ripped using the method presented in the last chapter from 
128x128 textures and then modulated with different colors.) T he fringes look a lot better than just having 
the two different terrains placed together with no sort of transition at all. 
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Figure 21.3 
Another fringe example 
showing transition 
between terrains 


ART REQUIREMENTS FOR FRINGES 


Believe it or not, | can do a fringe like the one shown in Figure 21.3 for a 64x32 standard iso tile shape 
with an image that is 128x64— exactly four tiles worth of information. Of course, this means a lot 
of on-the-fly modulation of textures with the fringes, which decreases performance by quite a bit. 


First, let's take a look at some basic math. For any given tile, the fringe that needs to show within that tile 
depends on all its neighbors. If you consider a case in which only two types of terrain exist, the neighbor- 
ing tiles will ether be of the same terrain or of the other terrain. Since each tile has aght neighbors, that 
is 2 to the eighth power, or 64 combinations. If your terrain is ripped from a texture, meaning that you 
could possibly have 2, 4, 8, 16, or even more different tiles that represent that same terrain, you are look- 
ing at anywhere from 128 to 1,024 or even more different images that can appear for a tile 


Since it is very likely that you have more than two types of terrain, the number keeps increasing. T he cold, 
hard fact is that you dont have enough display memory to store the fifty bazillion images for the various 
fringe pictures, which would be ideal for performance. So, you have to compromise by taking a little away 
from performance to reduce the requirements of the art to a manageable level. T hat is what I'm here to 
show you how to do. 


Before going оп, 165 take a look at what kind of requirements you would have for art if you were to make 
a distinct image for every possible tile configuration. I'm going to deal only with the fringing for coastline, 
which is, in my opinion, the best example of using a fringe. First, you must decide which type of terrain 
(either land or water) is "on top” of the other. T he type of terrain "on top” does not get a fringe written 
on top of it, but the "on the bottom" terrain does. Logically, land is on top of water, but this could go 
either way. In most games you will see, the fringe/ coastline is written onto water tiles and not onto land 
tiles, but this is a convention, not something that's written in stone 
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To illustrate the point, | present Figure 21.4, which shows various representations of a 3x3 tile neighbor- 
hood. T he lightly shaded tiles represent water, and the darkly shaded tiles represent land. N otice that the 
central tile of each neighborhood is a water tile, since it is upon the water tiles that you will be placing 
the fringe/ coastline. 


Figure 21.4 


A tile neighborhood with 
tiles representing water 
and land 


МИН 
Оооо н 


If you count the neighborhoods іп Figure 214, there аге 256 of them, and each neighborhood configura- 
tion 15 represented exactly once. Ideally, you would provide images for each of these, and if you had such a 
simplistic map— only water and land— you could probably get away with that. Н owever, you usually can- 
not spend the display memory required for 256 images when you also need units, the units’ animation 
frames, various types of land terrain, buildings, and so on. 


If having 256 distinct images just for coastline is wasteful, what do you do? М у own way of getting 
around the prohibitive art requirement for coastline (and other fringes) is to divide the tile into zones, as 
shown in Figure 21.5. 
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Figure 21.5 


A tile divided into zones 


W ith the tile divided into zones, you can just consider a single zone and its neighbors. Figure 2 1.6 shows 
an analysis of the possibilities for the upper-left zone. As you can see, there are eight possibilities, so an 
image that covers just the upper-left zone of the tile shape would need eight images. D о the same thing for 
each of the other three zones. A total of 32 images is needed, which is already much better than 256, but 
you arent done yet! 


Figure 21.6 


N eighbors of a fringe 
tile zone (upper left) 
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T he last picture! have to show you before we get into a more concrete example is Figure 21.7, which 
shows the actual fringe for the upper-left tile zone based on the value of its tile neighbors. Eight tile neigh- 
borhoods are shown in this figure, but if you look closely, you will see that whenever the northwest tile is 
land, the same fringe is shown in the central tile. Since this occurs in four of the eight configurations, you 
can eliminate three of the eight pictures you would otherwise require. Similarly, when all of а water tiles 
neighbors are also water, no picture is needed, so that eliminates another picture needed. N ow you have 
just four images required per tile zone, for а total of 16 pictures, which is hardly any at all. 


Figure 21.7 


Actual fringes based on 
a Ше5 upper-left zone 


| ve seen a number of people flounder when trying to get some sort of coastline or fringing working, usu- 
ally because they try to make an image for every possibility, which is completely unnecessary. I'm here to 
show you the easy way, if not the fastest. 


MAKING A LOOKUP TABLE 


For the time being, give each of your images for each tile zone the numbers 0 through 3.T he actual 
images reflected by this number will be arbitrary. N ow, the easiest thing to do is to take the values (land = 
1, water = 0) of the tile neighborhood for a given zone and map them to the image numbers. (T his way, 
you can do coastline image lookup with a simple array rather than a bizarre set of if statenents.) 


| count my directions clockwise, just as a convention, and | see no need to stop doing so now. For tile 
zones, | will start with the upper left and move clockwise to hit the other zones. 
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UPrPER-LEFT TILE ZONE 


T he three neighboring tiles are those to the west, the northwest, and the north, in clockwise order. 
Check out table 21.1. 


Table 21.1 LookupValues for the U pper-Left Corner 


West Northwest North Value Image 
W ater W ater W ater 0 -1* 
Land W ater W ater 1 0 

W ater Land W ater 2 1 

Land Land W ater 3 1 

W ater W ater Land 4 2 

Land W ater Land 5 3 

W ater Land Land 6 1 

Land Land Land 7 1 


“Тһе number -1 indicates that no fringe exists for this configuration. 


Remember that | said earlier that the northwest neighbor dominates the choice of image?T hat's what 
is happening here. T he image number assignments, as you can see, are completely arbitrary. 


UPPER-RIGHT TILE ZONE, LOWER-RIGHT TILE ZONE, 
AND LOWER-LEFT TILE ZONE 


T he work is finished, actually. You can use the same table; just use different directions in place of the ones 
used for the upper-left zone. 


» Upper right. U se north, northeast, and east. 
» Lower right. U se east, southeast, and south. 
» Lower left. U se south, southwest, and west. 


T hink ahead, keep it simple, and never write a convoluted mess of 1+/ else blocks when a perfectly good 
lookup table can be used in its stead! 
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NOTE 

More than just the three tiles listed for each zone affect that zone. For example, for the 
upper-left zone, І listed the west, northwest, and north tiles.To this list you should add 
southwest and northeast.W hy didn't I list these earlier? Because the southwest counts 
the same value as the west tile, and northeast counts the same as north.T his would 
have just made the previous table more confusing. Just keep this in mind during the 
code example. 


A FRINGING EXAMPLE 

Blah blah blah! All | seem to do is talk anymore! W dl, it's time for another code example. Warm up the 
isometric components, for you shall be making use of them, although this wont be nearly as complicated 
as some of the stuff back in Chapter 17! 

І5ОН e21 1.срр and associated files make up a very simple editor. T hey demonstrate my fringing algo- 
rithm to make coastline. It's not the most convincing coastline by any means, but it should get the idea 
across. 

Figure 21.8 shows the coastline example. Because of how the fringe was drawn, there is still something of 
a “blocky” appearance to the map, but the difference is less stark than it would be if green land tiles were 
laid next to blue water tiles without any sort of transition. 


Figure 21.8 


Coastline example, 
IsoHex21 1.срр 
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T he vast majority of IsoH ex21 1.срр is much the same as the examples in Chapters 17 through 19, 
using the IsoH exCore components to take care of the details of isometric management. | wont bore you 
by repeating descriptions of these components. M ainly, I’m going to concentrate on what makes this 
example unique. 


MAP STRUCTURE 


First | changed the way in which the MapLocation structure looked, in order to accommodate the fringes. 
| ripped out all the stuff for managing units so that | could highlight the stuff necessary for fringes. T he 
following is what MapLocation looks like: 


const int UPPE 
const int UPPE 
const int LOWE GHT22; 
const int LOWERLEFT=3; 
//map location structure 
struct MapLocation 

{ 


LEFT=0; 
RIGHT=1; 
R 


R 
R 
R 
R 


bool bLand; 
int iFringe[4]; 


}; 

MapLocation mlMap[MAPWIDTH][MAPHEIGHT];//map array 
//fringe lookup table 

int FringeLookUp[8]={-1,0,1,1,2,3,1,1}; 


It’s still a very basic structure. First, it contains a single роот that is true when that location contains land 
and false when it contains water. Іп amore complicated example, this would very likely be replaced with 
an int, with 0 representing water, 1 representing grassland, and 2 and up representing different types of 
terrain. For now, а boo1 suffices. 


T he next bit is a four-item array called Fringe. Each of the items in this array contains a value for what- 
ever fringe exists at that particular map location— one for each of the four tile zones. T he four constants 
in the code snippet give names to the four regions. 


Lastly, the FringeLookUp table (an eight-item array) contains the lookup values for tile images, which 
we talked about earlier. A - 1 value means no fringe is to be rendered. 


RENDERING FUNCTION 


N aturally, the next thing is the rendering function. We'll get to how the MapLocation structure array 
(m1Map) gets filled in and calculated in a moment. 
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Н ere a basic rundown of RenderFunc before we get to the actual code. First, if bLand is true, you render 
land and ignore the values in iFringe. Second, if bLand is false, you render a water tile and then put in 
each of the appropriate fringes if applicable. 


void RenderFunc(LPDIRECTDRAWSURFACE7 lpddsDst,RECT* rcClip,int xDst,int yDst,int 
xMap,int yMap) 
{ 


//check land or sea 

if(mIMap[xMap]LyMap].bLand) 

{ 
//land 
tsBack.ClipTile(lpddsDst,rcClip,xDst,yDst,0); 


First case: If bLand is true, render the land tile, and that's it. N o other activity is required for this map 
location. Both the land and the sea tiles are stored in tsBack. Land has a Ше index of 0, and sea has an 
index of 1. 


else 

{ 
//sea 
tsBack.ClipTile(lpddsDst,rcClip,xDst,yDst,1); 


Case, the second (to emulate my friend M ason's manner of speech): bLand is false, which means you need 
to render the sea tile (tile index 0 of tsBack) and then render any of the fringe images as appropriate. 


//upper-left zone 
if (FringeLookUpLmIMapLxMap]LyMap].iFringeLUPPERLEFT ]]>=0) 
tsFringe.ClipTile(lpddsDst,rcClip,xDst,yDst, 
FringelLookUp[mlIMap[xMap]LyMap].iFringe[UPPERLEFT]1); 


A quick heads-up: the items in irringe contain numbers 0 through 7, indicating land in neighboring tiles. 
In order to determine which fringe image should be rendered, you first have to plug that number into the 
FringeLookUp array, which you do here. If it is greater than or equal to 0 (that is, not - 1), go ahead and 
render the image you looked up. If it is - 1, skip it. 


//upper-right zone 
if(FringeLookUp[mlMap[xMap]LyMap].iFringeL[UPPERRIGHT]]»-70) 
tsFringe.ClipTile(lpddsDst,rcClip,xDst,yDst, 
FringeLookUp[mlMap[xMap]LyMap]l.iFringe[UPPERRIGHT]]-4); 
//lower-right zone 
if(FringeLookUp[mlIMap[xMapl[yMap].iFringeL LOWERRIGHT] ]>=0) 
tsFringe.ClipTile(lpddsDst,rcClip,xDst,yDst, 
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FringeLookUp[mlMap[xMap]LyMap].iFringe[LOWERRIGHT]]-*8); 
//lower-left zone 
if (FringeLookUp[m|lMapLxMap]LyMap].iFringelLOWERLEFT ] ]>=0) 
tsFringe.ClipTile(lpddsDst,rcClip,xDst,yDst, 
FringeLookUp[mlMap[xMap]LyMap].iFringe[LOWERLEFT]]-*12); 


} 


You do the same thing for the other three tile zones: upper-right, lower-right, lower-left. | like doing things 
clockwise. It seems more organized that way. 


So, that's it for RenderFunc. It seems incredibly simple and, in fact, it is. T he hard part was done several 
pages ago, divvying up the tile shape into zones, and coming up with lookup tables. T hinking ahead 
pays off! 


CALCULATING THE FRINGE 


№ aturally, the numbers in irringe for all the map locations dont just magically appear out of nowhere. 
T hey were carefully calculated by several functions. Let's get to them! 


THE CALCFRINGE FUNCTION (PART 1) 


OK, it's not the most original name for a function, | admit (1 tend to make up uninteresting function 
names). T his function, to no ones surprise, calculates all the fringes for the entire map. 


void CalcFringe() 

{ 
//loop through x 
for(int x=0;x<MAPWIDTH; x++) 
{ 


//Лоор through y 
for(int y=0;y<MAPHEIGHT;y++) 
{ 


//calc the fringe 
CalcFringe(x,y); 


} 


T his is one of the CalcFringe functions. T here are two, and the other one is next. If any of you С pro- 
grammers are feeling faint because | have two functions with the same name, just take a deep breath and be 
а trouper. 
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T his CalcFringe function takes no parameters, returns no values, and simply loops through the entire 
map, sending each (x,y) location to the other calcFringe function. 


THE CALCFRINGE FUNCTION (PART E) 


T he second calcFringe function takes two parameters (an x- and y-coordinate), returns no value, and 
does most of the fringe calculation (the other functions just pass information along to this one).. 


void CalcFringe(int x,int y)//calculate for individual map location 
{ 
//range checking 
if(x«0) return; 
if(y«0) return; 
if(x>=MAPWIDTH) return; 
if (y>=MAPHEIGHT) return; 


First, check to see if (х,у) corresponds to a valid map coordinate, so if x or y is less than 0 or equal to or 
greater than MAPWIDTH ОГ MAPHEIGHT, respectively, you return immediately. T his means you can call this 
CalcFringe without fear. 


//calculate the tile neighborhood 
bool Neighbor[8]; 

//store starting point 

POINT ptStart; 

ptStart.x=x; 

ptStart.y=y; 

//next map location 

POINT ptNext; 


T his next bit gets a little confusing, because of all the conditional code, so let me clue you in to exactly 
what you're doing. Youre storing the values of the tile neighborhood in a temporary array of ints (called 
Neighborhood). T he value of 0 means a water tile, and 1 means a land tile. T hese values, in turn, will be 
used to determine the i Fringe values for this map location. Got all that? Let's dive in! 


for(int dir=0;dir<8;dirt++) 

{ 
//walk to neighbor 
ptNext=TileWalker.TileWalk(ptStart, (ISODIRECTION) dir); 


A variable called ptStart contains the current (x,y) position, so use {пет ileWalker to determine what tile 
lies in a given direction (loop through them all using the variable dir). О nce you have the neighboring 
map location, you can test it for land or water. 
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//range check 

if(ptNext.x«0 || ptNext.y<O || ptNext.x>=MAPWIDTH | | 
ptNext.y>=MAPHEIGHT ) 

{ 


//out of bounds 
NeighborLdir]=0; 


T he first check, of course, is a bounds check. If ptNext does not exist on the map, set this neighbor to 0, 
meaning water. Really, you could default to 1 or land; it doesnt really matter. Generally, however, it is 
assumed that outside of the map is open ocean. 


else 

{ 
//check map location 
if(mlMap[ptNext.x][ptNext.y]l.bLand) 


//land 
Neighbor[dir]-1; 


//water 
Neighbor[dir]-0; 


If ptNext is not out of bounds, you can check the value of bLand at that map location and assign 1 for 
true and 0 for false. T hen you can loop through the remaining values of dir. 


//determine zones 
miMapLptStart.xJ[ptStart.y].i 


ingeLUPPERLEFT J=(Neighbor[6]+2*Neighbor[7 1+ 
4*Neighbor[0])|(Neighbor[5]+4*Neighbor[1]); 
apLptStart.x][ptStart.y].iFringeLUPPERRIGHT J=(Neighbor[0J]+2*Neighbor[1]+ 
4*Neighbor[2])|(Neighbor[7]+4*Neighbor[3]); 
apLptStart.xJ]J[ptStart.y].iFringeLLOWERRIGHT J=(Neighbor[£2]+2*Neighbor[3]+ 
FEL 
rin 
3 


4*Neighbor[4])|(Neighbor[1]+4*Neighbor[5]); 
ingeLLOWERLEFT J=(Neighbor[4]+2*Neighbor[5 1+ 
j*4*Neighbor[71); 


ap[ptStart.x][ptStart.y].iF 
4*Neighbor[6]) | (Neighbor[ 
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And finally, the end of the function with some crazy-looking equations. | used numbers here instead of 
the 150_* constants mainly because not doing so would make all the lines 10 miles long. 


To better explain what the heck is going on, I'll convert the first line into the 150_* constants. 


mlMap[ptStart.x][ptStart.y].iFringe[UPPERLEFTJ- 
( 


l*Neighbor[ISO WEST]- 
2*Neighbor[ISO NORTHWEST ]+ 
4*NeighborLISO+NORTH] 


yd 


1*NeighborLISO_SOUTHWEST ]+ 
4*Neighbor[ ISO. SOUTHEAST] 


T his should be a little easier to read. Remember that for the upper-left tile zone, you build a value based 
on five tiles: W est or southwest is 1, northwest is 2, and north or northeast is 4, giving you a value from 
0 to 7.T hat's all you're doing here, in a very concise form. 


THE CALCFRINGENEIGHBORHOOD FUNCTION 


T he final fringe calculation function is Ca1cFringeNeighborhood. Supply it with an (x,y) coordinate, and 
it recalculates not only that map location, but all map locations surrounding it. T his function isnt used in 
this example, but if you were to, say, modify this program so that bLand were changed for whatever map 
location you dicked on, you would want to recalculate not only that tile, but also all tiles around it. 


void CalcFringeNeighborhood(int x,int y)//calculate for a tile neighborhood 
{ 

//send tile (x,y) to calculate fringe function 

CalcFringe(x,y); 

//store center point 

POINT ptCenter; 

ptCenter.x=x; 

ptCenter.y=y; 

POINT ptNeighbor; 

//\oop through directions 

for(int dir=0;dir<8;dir++) 

{ 


//determine neighbor 
ptNeighbor=TileWalker.TileWalk(ptCenter, (ISODIRECTION) dir); 
//send neighbor to calculation function 
CalcFringe(ptNeighbor.x,ptNeighbor.y); 
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T his function is no great feat of computer science. | simply use theT ileW alker to walk around the center 
tile and send the (x,y) values to CalcFringe.T he function is, however, of great use when youre construct- 
ing an editor that has to maintain coastlines or fringes. 


A FINAL NOTE ABOUT FRINGES 


| certainly hope! was able to demystify and simplify fringes and coastline for you. M y own first attempts 
at making them were rather unsuccessful. | would either take up too much space with the images, or some 
thing else would go wrong and the resulting pictures looked awful. Eventually | stumbled upon this algo- 
rithm, which makes life much easier. 


H owever, it would be arrogant of me to say that my coastline algorithm is the best ever. M y coastline algo- 
rithm requires anywhere from one to five blits per map location, and if there is a lot of coastline, this can 
affect performance detrimentally. |t wont matter so much once you get to iso-3D later on, but it seems to 
me that there should be a less-performance intensive solution that is also not very art-intensive. If you find 
one, be sure to let me know! 


INTERCONNECTING STRUCTURES 


T his is possibly the vaguest heading I've come up with. W hen | say interconnecting structures, | primarily mean 
two things: rivers and roads. T hese arent the only applications of interconnecting structures, of course. 
You can also make forests, hills, mountains, walls, and so on as interconnecting structures, but rivers and 
roads are the best examples and are the easiest to use for teaching. 


l'm going to show you two basic methods for isometric tiles— one that uses four directions and one that 
uses eight directions. Generally, the four-direction version is more commonly used for rivers and the eight- 
direction for roads, but either can be adapted for use іп a number of areas. l'm only going to show you 
roads (because they are easy to draw). 


FOUR-DIRECTION STRUCTURES 


As | stated, a four-direction connecting structure is commonly used for rivers, but | have also seen it used 
for forests, hills, mountains, and walls. In all cases, the lines of the connecting structure (the road or river, 
or the base line of the wall or trees) connect the center of onetileto the center of an adjacent tile. 


In the four-direction version, you use the diagonal directions— northeast, southeast, southwest, and north- 
west. Truth be told, you could use the cardinal directions instead, but the diagonals line up nicely with the 
faces of the rhombus, and in my opinion, it looks nicer. 
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A FOuUR-DIRECTION EXAMPLE 


Load up 150Н ех21 2.cpp. Figure 2 1.9 shows this particular example. Т his program isnt much, but it does 
do interconnected lines (meant to simulate roads— ту mediocre artistic talent shows again). 


Figure 21.9 


Four-direction 
interconnectedness 


T his program is an awful lot like IsoH ex21 1. In fact, all | had to do was rip out a few variables, change а 
few function names, rewrite the rendering function, and poof, | had the new example. 


MAP STRUCTURE 


T he most fundamental change, of course, occured in the structure that contains information for a map 
location. D ealing with roads is a little less involved than dealing with fringes and the four tile zones. 


//road flags 

const int ROAD _NORTHEAST=1; 
const int ROAD_SOUTHEAST=2; 
const int ROAD SOUTHWEST-4; 
const int ROAD NORTHWEST-8; 
//map location structure 
struct MapLocation 

{ 


bool bRoad; 
int iRoad; 


Із 
MapLocation mlMap[MAPWIDTHJ[MAPHEIGHT];//map array 
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First, you have the road flags (all the вол) * constants at the top). | store road direction information in 
individual bits rather than in a роот array (which is just as good, by the way). T hese flags, and combina- 
tions of them, are stored in the iRoad member of MapLocation.T he other member of MapLocation, 
bRoad, Indicates whether or not a road runs through this particular tile. In this simple mode of reality, 
aroad either runs through an area or it doesnt, period. 


W hen initializing this map during Prog Init, | simply set bRoad randomly to true or false, as 
shown next. 


//set up the map to a random tilefield 
int x; 
int y; 
for (x=0;x<MAPWIDTH; х++) 
{ 
for (y=0; y<MAPHEIGHT ; y++) 
{ 
if(rand()&l) 
{ 
mlMap[x][y].bRoad=true; 


mlMap[x][y].bRoad=false; 


} 
//calculate the fringe 
CalcRoad(); 


T his little bit of code takes no great programming skill, but it's kind of hidden amid the IsoH exCore 
initialization calls in Prog_Init, so | thought I'd point it out for you. [п the case of the example, | can 
get away with this totally random map. Іп a game, you'd probably load the map from disk, or generate the 
world (see Chapter 22 for more on world generation). 


RENDERING A MAP LOCATION 


Besides the change to MapLocation,| also had to completely rewrite RenderFunc, but this should come as 
no surprise to you, since! couldnt possibly use the fringe version to render roads. 
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void RenderFunc(LPDIRECTDRAWSURFACE7 1рааѕрѕі, КЕСТХ rcClip,int xDst,int yDst,int 
xMap,int yMap) 
{ 


//put down a land tile 

tsBack.ClipTile(lpddsDst,rcClip,xDst,yDst,0); 

//check for a road 

if(mIMap[xMap]LyMap].bRoad) 

{ 
//put the road image 
tsRoad.ClipTile(lpddsDst,rcClip,xDst,yDst,mlMap[xMap]LyMap].iRoad); 


T his RenderFunc Is vastly simplified from that of the fringe You render the background tile for every 
map location and then render the road on top of it, but only if bRoad is true for that map location. Since 


you're storing road flags in i Road, simply make the number (0 through 15) correspond to numbers within 
the tsRoad tileset. 


THE CALCROAD FUNCTIONS 


Of course, the values in iRoad dont just magically appear— they must be calculated. T hus, | created the 
CalcRoad functions— one with no parameters that performs calculations for the entire map, and another 
that calculates the value for only a single map location. 


void CalcRoad() 
{ 
// loop through x 
for(int x=0;x<MAPWIDTH;x++) 
{ 
//loop through y 
for(int y=0;y<MAPHEIGHT; у++) 
{ 
//calc the fringe 
CalcRoad(x,y); 


} 


T he void parametered ca1cRoad performs much the same function as the void parametered CalcFringe. 
In fact, it is the same code with "Fringe" taken out and replaced with “Road.” Cheap and easy, the way 

| like it! T he second Ca1cRoaa function takes two parameters— the x and y map location to calculate. 
You'll probably note a striking similarity between this function and the calcFringe(x,y) function in the 
prior example. A gain, cheap and easy. 
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void CalcRoad(int x,int y)//calculate for individual map location 
{ 


//range checking 

if(x<0) return; 

if(y<0) return; 

if (x>=MAPWIDTH) return; 

if (y>=MAPHEIGHT) return; 
//calculate the tile neighborhood 
bool Neighbor[8]; 

//store starting point 

POINT ptStart; 
ptStart.x=x; 
ptStart.y=y; 
//next map location 

POINT ptNext; 

for(int dir=0;dir<8;dir++) 
{ 


//walk to neighbor 

ptNext=TileWalker.TileWalk(ptStart, (ISODIRECTION) dir); 

//range check 

if(ptNext.x«0 || ptNext.y<O || ptNext.x>=MAPWIDTH | | 
ptNext.y>=MAPHEIGHT ) 

{ 


//out of bounds 
Neighbor[dir]-0; 


else 
//check map location 


if(mlMap[ptNext.x][ptNext.y].bRoad) 
{ 


//road 
NeighborLdir]=1; 


//no road 
Neighbor[dir]-0; 


} 


//clear road flags 
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mIMap[x]1Lyl.iRoad-0; 

//add road flags as appropriate 
if(Neighbor[ISO NORTHEAST]) mlMap[x]Ly].iRoad|-ROAD, NORTHEAST; 
if(Neighbor[ISO SOUTHEAST]) mlMap[x]Ly].iRoad|-ROAD, SOUTHEAST; 
if(Neighbor[ISO SOUTHWEST]) mlMap[x]Ly].iRoad|-ROAD, SOUTHWEST ; 
if(Neighbor[ISO NORTHWEST]) mlMap[x]0y].iRoad|-ROAD, NORTHWEST ; 


| 


T he vast majority of the ca1cRoad function is unchanged from its former incarnation as the Ca1cFringe 
function, except when you get to the last few lines. First, you clear out any prior воло_* flags by setting 
iRoad to 0.T hen, you check each of the pertinent directions (the diagonals) and tack on the appropriate 
ROAD. * flag. It’s pretty self-explanatory, since | managed to use constant names instead of raw numbers. 
You wind up with a value from 0 to 15 for iRoad, and that gives you the index into the tileset that is 
used by RenderFunc. 


H opefully, you can now see why fringes and interconnecting structures were discussed in the same chapter, 
since the algorithms used to determine what to show are closely related. Oh, and if you want to see an 
example of interconnected structures that looks more impressive than the very simple roads, you can go 
ahead and make tsRoad load in a bitmap called wallts.bmp, which replaces the road images with images 
of walls. 


USING THE FOUR-DIRECTION METHOD 


As stated earlier, you can use the four-direction method for roads, rivers, forests, hills, mountains, walls, 
and a lot of other stuff. T here are а few things | want to mention before going on. 


First, the four-direction method requires only 16 pictures, which is acceptable. You have to take care, how- 
ever, to make these pictures line up properly (it took me a good half an hour to make even the simplistic 
roads look right). T he easiest way to do this isto put a few tiles on a bitmap, with the centers marked, 
and draw images between the centers to the northeast and southeast, and then crop out the images for 
each direction. It's a painstaking process, but the results are faster than with trial and error. 


A note about rivers: undoubtedly, you will want your rivers to empty into oceans or seas of some sort 
(since real-life rivers tend to do that). Combining rivers and fringes can get a little hairy, since you have 
to create graphics for the mouths of rivers. T his adds only four extra images, but | felt it was worth 
pointing out. Also, you have to mark the ocean square into which the river empties as a river square, 

so that the coastal image comes out correctly when you call ca1cRiver (or whatever you call your river 
calculation function). 
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EIGHT-DIRECTION STRUCTURES 


T he aght-direction structures are usually only used for roads, railroads, and so on. M ost other types 

of structures use only four directions. T he aght-direction structure can be a severe liability to video 
memory or performance, especially if the connecting structures are quite common in the game, as 

roads tend to be. T here are two methods you can use to make eight-direction structres— the high-perform- 
ance and video-memory-costly solution, or the high-video-memory, low-performance solution. 


T he high-performance version requires a different image for each possible configuration. Since there are 
eight directions and two possible values for each direction, the number of pictures required is 2 to the 
eighth power, or 256. T he advantage is that it adds only a single layer to the map, no matter what configu- 
ration the road is in. T he disadvantage is that it requires 256 images in order to do so. 


T he low-performance version requires one image for each direction. T hese images are combined during the 
rendering to make the composite image Т his requires only eight pictures. T he advantage is that you have a 
lower video memory requirement to ge it done. T he disadvantage is that it adds anywhere from one to 
eight layers, which can adversely affect performance if there are many roads. 


So, which to use? If performance isnt as much of an issue, as with many turn-based strategy games, go 
ahead and use the lower- performance version. If speed is required, and you have the video memory to 
spare, go ahead with the higher-performance version. 


T he calculation of eight directions is much the same as that for four directions, except that you dont 
ignore any of the directions (duh), so | wont offer a whole extra example of something that I'm confident 
you can figure out on your own, based on the other examples from this chapter. 


SUMMARY 


Fringes and interconnecting structures are very important in isometric games, and knowing how to work 
with them will greatly improve the appearance of your games. Still, there is the specter of video memory 
versus performance, although with modern video cards, available video memory increases, and the efficien- 
cy of blitting increases, and both problems diminish. Still, that’s no reason to be sloppy. 


T his part of the book has been sort of a hodgepodge of stuff, starting with optimization and ending with 
artistic concerns. | hope it has been an enlightening journey. W еуе got а few more topics to cover, but 
with your arsenal of isometric knowledge, you are ready to face the challenges of Al and 150-30. 
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elcome to the first part of the final leg of the journey through isometric land. You've mastered 

quite a few isometric tricks to optimize and enhance the look of your game. H owever, you've 
mainly been concerned with rendering, and as you Know, being able to blit an image onto the screen does 
not а дате make! Indeed, а game needs more It needs something to set the stage behind the scenes, before 
you render even a single pixel. Т hat is what this chapter and the next cover. 


In a moment, 1711 get into world generation. T his is a rather ambitious topic for a single chapter, for а cou- 
ple of reasons. First, since many types of games make use of the isometric perspective, it is difficult to 
offer a comprehensive solution for every possible circumstance. Second, there is never a single way to do 
anything, and world generation is no exception. 


As a result, | can only give you some very general world-generation algorithms and some vague hints to 
head you in the right direction. D ecent world generation involves trial and error. T he goal is to be reason- 
ably convincing with the finished product; it doesnt have to be perfect. 


WHAT 15 WORLD GENERATION? 


N aturally, before getting into this topic, you should take a moment to understand exactly what world 
generation means and what your goals are. Foremost, the goal of world generation is to generate worlds. 


And what is a world? If you are playing a strategy game, the world might consist of a single isometric map. 
A dungeon-crawling game might involve several maps, each with its own unique look and configuration. 
So, by world, | mean all the places in the game that the player might visit. W hat, then, are your goals when 
generating worlds? 


= Cohesiveness. Your worlds need to be cohesive. In other words, they must make sense. T his doesnt mean that 
they have to be accurate representations of the real world, but there should be some sort of internal consis- 
tency. For example if | travel out of a room through a door to the west, | fully expect that when | arrive in 
the new room, there should реа door on the east, or there should bea logical reason why there isnt a door 
going back (for example, it might be a magical one-way door, or maybe there was a cave-in after | passed 
through the door and triggered a trap). 


= Believability. Again, your world does not have to adhere to the real world, but some sort of “reality check” 
should be performed. For example, you are not likely to find a desert right next to a swamp, and a good 
world-generation algorithm will not combine two such unrdated dements. Instead, the algorithm would put 
something in between, like grassland or plains. 
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As another example, imagine a room with four walls, a door in each. Each door is about the size of anormal 
door in the real world (when game scale is taken into account). H ow, then, would a monster the size of a 
dragon (dragons bang much larger than the doors) get into this room? If there is a decent justification for 
this apparent conflict, that's fine. Just dont make weak justifications. (“U m, a dark priest, yeah, that's it, a dark 
priest took the dragon egg and, um, brought it to this room, and һе, по, he, um, wall, anyway, it hatched, and 
the dragon grew up, and, um, that's how the 50-foot-long dragon is here in a room with doors it wont fit 
through.”) 


= Playability. С ames, for the most part, are finite in scope Т hey have a beginning and an end. U sually, the end 
is brought about either by total defeat or by meeting certain criteria at which point the player is said to have 
won the game. N ot all games have a "win" condition, but almost all of them have a "lose" condition, or at 
least a “stalemate” of some sort. 
W hat does this have to do with world generation? Q uite simply, if there is a win condition, the world gener- 
ator must create a world in which reaching that goal is possible. It does not need to make achieving that goal 
easy, but it should not render it impossible. 


= Replayability. Separate and distinct from playability, replayability enhances а game's value immensay. 
Generally speaking, world generation uses some sort of random determination in order to put the pieces of 
the world together in a coherent, believable, and playable manner. W hen you go back and start a new game 
from scratch, you should have before you the same basic elements of the game you played before, but in a dif- 
ferent order and in a variation you have not seen already. T his keeps a game from getting stale and winding up 
on someone’ shelf after it was played through a single time (I've got a few of these kinds of games). 


USING MAZES 


“W orld” is a rather vague term. It can mean anything. Some worlds might be continents and oceans, as in 
empire-building games. О thers might have wilderness locales or underground dungeons. [п the latter case, 
mazes can be utilized to generate unique worlds. 


M azes are not limited to the labyrinth-type structures we think of, or the little cardboard tabletop things 
that lab mice run through in search of cheese. M azes can simply tell you a path from one location to 
another, no matter if the nature of the location is a bunch of forest paths, an underground cave, some sort 
of building, a river, and so on. 


T he algorithm I'm about to show you builds a 2D maze of any size and can be extended to create 3D 
mazes. I've even done 4D mazes, but you shouldnt really think about those unless you want your brain to 
short out! (Plus, they are extremely difficult to map out.) 


M azes are an integral part of the games you play, whether those mazes are obvious or not. Knowing how 
to generate a maze and how to use it to build a world will take you far. 
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WAAT 15 A NAZEF 


It seems like a silly question, | know, but as you have by now figured out, | like defining things so that 
there arent any embarrassing questions later. You already know what а таге і, l'm sure 


A mazeis a series of locations (they could be rooms, clearings in a forest, caves, whatever) connected by 
passages of some sort (hallways, doors, portals, paths). In a basic maze, with no trickery going on, 

any location in the maze can be reached from any other position in the maze by navigating the many 
passages. їп English, that means you can get from one end of the maze to another— there is a solution. 
Generally, these passages follow some sort of rule so that the maze can be mapped on a normal piece of 
paper or graph paper. T his is not always so, however, especially if there are portals that teleport you from 
one location to another. 


CREATING A MAZE 


T he algorithm I'm going to show you is rather plain. It has locations and passages, but nothing else. N o 
secret doors, no one-way doors, no locked doors, no magic portals. T his is intentional. You create a basic, 
plain maze and then populate it with special features like those | just listed. 


To start, you must have some sort of structure into which you can place data for a distinct location in the 
maze. | usually call these "rooms" even if they arent used to make rooms in a world. 


//constants to use for directions 
const int MAZE_NORTH=0; 


const int MAZE_EAST=1; 
const int MAZE_SOUTH=2; 
const int MAZ EST=3; 


//number of doors possible 
const int MAZE_DOORCOUNT=4; 
//room structure 

struct Room 


{ 


по rn rn rn г 
О | 


//array of doors leaving this room 
bool Door[MAZE_DOORCOUNT J; 


1% 


You're looking at this, saying, “Y ouve got whether or not the doors exist, but you dont have where the 
doors lead!” Well, you're right, but in my defense, | haven't stated the rules for this maze yet. | also call the 
passages between rooms "doors" even though they might not be doors when I’m finished. 
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You will place the rooms in a rectangular grid of any size and call it MAZE_WIDTH by MAZE_HEIGHT. 
So, you'll make an array of rooms. 


//room array 
Room Maze[MAZE_WIDTH]J[MAZE_HEIGHT]; 


If you are іп any given room and you travel in a direction, the x and y coordinate within the grid will 
change based on the data listed in Table 22.1. 


Table 22.1 Maze Direction and Change in Location 


Direction X Y 
МАЈЕ NORTH +0 -1 
MAZE_EAST +1 0 

MAZE_SOUTH +0 +1 
MAZE_WEST -1 +0 


As usual, | start with north and rotate clockwise from there, as is my habit. То begin the maze, start with а 
completely blank array of Room structures. It is a completely clean slate, a fresh piece of paper, upon which 
your maze will be born. 


T he first time around, you can just pick a room randomly and place a door that will connect two of the 
rooms. T hereafter, until the maze is complete, you must pick a room with a door already in it and figure 
out whether or not you can add another door to it. If you can, add one. If not, pick another room. 


T heres an important concept to point out here. О ne door connects two rooms. Adding another door con- 


nects three, and so on. W hen you are all done, you will have one door less than the number of rooms. For 
example, in a maze with MAZE_WIDTH*MAZE_HEIGHT, you will have MAZE WIDTH*MAZE HEIGHT-1 doors. 


For your purposes, you'll disallow wrapping around the maze, meaning that you cant go west from the 
westmost rooms and wind up on the eastern side of the map. 

W ithout further ado, here is the maze-generation code. You can find this function in 150Н ex22_1.cpp, 
which is a simple little program that demonstrates a maze being built using the GD | method for drawing. 


void MakeMaze() 
{ 


//start making the maze 
//assumes the maze array is clean (i.e. all values are false) 
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int doorcount=0;//number of doors we have placed 

//х and у position of the room 

int x; 

int y; 

int dir;//direction 

//randomize the seed 

srand(GetTickCount()); 

//clear out the maze 

for (x=0;x<MAZE_WIDTH; х++) 

for(y20;y«MAZE HEIGHT; y++) 
for(dir=0;dir<MAZE_DOORCOUNT;dir++) 
MazeLx]Ly].Door[dir]=false; 


Before you do anything, make sure the data is properly initialized. T his means that you must clear the 
maze so that all doors are false. Failing to do so might cause a garbled maze or might cause the program 
to hang. Actually, it is very likely that the program will hang indefinitely if you dont clear the maze. 


while (doorcount<MAZE_WIDTH*MAZE_HEIGHT-1) 
{ 
DrawMaze(); 
//this flag is set if a suitable room is found 
bool found=false; 
//blocks, used a little later 
int blockcount; 
bool block[MAZE_DOORCOUNT ]; 


Place each door individually. Іп order to do so, you must first find a place where a door can go, according 
to your door placement rules. T hat is what the found variable is for. T he blockcount and block variables 
are used to test whether a particular room can add a door. 


while(! found) 
{ 
//if doorcount is 0, just pick a room 
i f (doorcount==0) 
{ 
x=rand()%4MAZE_WIDTH; 
y-rand()ZMAZE HEIGHT; 


else 


//doorcount not zero, pick a room 
//with a door in it 
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do 


x=rand()%MAZE_WIDTH; 
y-rand()ZMAZE HEIGHT; 
} while (CountDoors(&Maze[x]LyJ)770) ; 
//CountDoors is pseudocode for 
//a function we'll write later 


T he first part of finding a suitable location for a door is picking a room, since all doors exist within 
rooms. D epending on the number of doors you have already placed (either попе or more than попе), you 
choose a room differently. W hen you have not placed any doors at all, any old room will do. After the first 
door, however, you must find a room with a door already in it. O therwise, your maze will not be navigable. 


//so far, so good, we have a room 
//we now must analyze blocked passages 
blockcount=0; 


Once you have picked a room candidate, verify that this room can add another door. N ot all rooms can. 
For example, a room in the corner of a maze can have only two doors. Also, a direction from one room 
might lead to a room that has always been created. T here are a few conditions for which you call a 
direction from a room “blocked.” 


//loop through directions 
for(dir=0;dir<MAZE_DOORCOUNT ; dir++) 
{ 
//set block to false 
block[dir]-false; 
//if the door in the room for dir is set, set the 
block 
if(Maze[x]Lyl.Door[dir]) 
{ 
block [dir]J=true; 
blockcount++; 
continue; 


T he first “blocked” condition is whether a door already exists in that direction. N aturally, you cannot 
place a door twice, so you mark that direction as blocked and continue with the loop through all 
the directions. 


//calculate the next position based on this direction 
int nx=x,ny=y;//next position 
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switch(dir) 

{ 

case MAZE_NORTH: 
{ 


пу; 
break; 
case MAZE_EAST: 
{ 
nx++; 
break; 
case MAZE_SOUTH: 
{ 
пу++; 
}break; 
case MAZE_WEST: 
{ 
nx-; 
}break; 
} 
//bounds checking 
if(nx<O || пу<0 || nx>=MAZE_WIDTH || ny»-MAZE HEIGHT) 
{ 
block[dir]=true; 
blockcount++; 
continue; 


T he second condition is whether the direction will cause you to leave the bounds of the maze. T he big 
switch statement just shown calculates the next position if you start at (x,y) and go in the direction of 
dir. If nx or ny is less than 0 or equal to or greater than MAZE_WIDTH Or MAZE_HEIGHT, mark this direc- 
tion as blocked and continue with the loop. 


//final check, make sure the room at nx,ny has no doors 
if(CountDoors(&Maze[nx][{ny])!=0) 
{ 

blockELdirJ=true; 

blockcount++; 

continue; 
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T he final test is to see whether a suitable destination lies on the other side of the wall, meaning that the 
room at (nx, ny) cannot have existed prior to this moment. If it has, set a block and continue the loop. 


//if blockcount is not the same as MAZE_DOORCOUNT, 
//we can place a door 
if(blockcount!-MAZE DOORCOUNT) found=true; 


If you have at least one opening after testing all the directions for blockage, you can place a door. 
//found is now true, so we can place a door 


do 
{ 
//select a door direction 
dir-rand()ZMAZE DOORCOUNT; 
while (block[dir]);//make sure that direction is not blocked 
//dir contains a valid direction 
Maze[x]Ly1.Door[dir]-true; 


To place a door, first pick a nonblocked direction. (T his is easy, because you have the block array, and 
you can just randomly choose until you find one that is false) O nce you have a suitable direction, 
place the door. 


//move to next room 
switch(dir) 
{ 
case MAZE_NORTH: 
{ 
у; 
}break; 
case MAZE_EAST: 
{ 


XT: 
}break; 
case MAZE_SOUTH: 
{ 


у++; 
}break; 
case MAZE_WEST: 


}break; 
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} 

//change direction to opposite direction 
dir=(dir+(MAZE_DOORCOUNT/2)) % MAZE_DOORCOUNT ; 
//set door in the next room 
Maze[x1Ly1.Door[dir]-true; 

//increment the doorcount 

doorcount++; 


} 


N ext, move the x and у position in the direction specified in dir. Reverse the direction and place another 
door so that the doors match. [п this manner, you guarantee that someone in the maze can go back the 
way he came. 


USING A MAZE 


All right, you've got a maze. N ow what to do with it?T he mazes generated by IsoH ех22 1.cpp are generic 
and simplistic— practically featureless except for the doors. {5 a great starting point, but you will want to 
do something to make the maze more interesting. A player will quickly get bored with such a simple maze, 
and boring the player is the last thing you want to do. N ow it's time for me to throw out two big words: 
variegate and populate. 


VARIEGATE 

Variegation just means “variety,” but it's a cool-sounding word and makes me seem smart. T he fact is, it 
just wont do to have а bazillion rooms all the same size and shape, with a wall missing wherever passage 
between rooms is allowed. 


Instead, you might want to make some rooms into chambers and others into hallways. You might want to 
place locked doors or hidden doors. You might even want to add a few extra nonessential doors just to 
make it less... well, maze-like If you put in locked doors in, be sure to put keys where the player can get 
to them. If you put in secret doors, be sure there is а way to detect them. And so on, and so forth. 


Or you might implement a maze as something that isn’t a dungeon or castle. A maze can just as easily be a 


bunch of forest paths or roads through mountains. Ога river system, or anything where passage from one 
area to another can occur. 


POPULATE 

T he scenery is only part of a world, and youre world-building here. So you need something of interest for 
the players to do in the maze (in whatever form it takes). T his can take the form of items, monsters, traps, 
N PCs (non-player characters), and so on. 
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Both variegation and population should follow some sort of rules that you come up with beforehand. 
For instance, you might decide that all dead ends are locked. Following this rule, you would need to create 
the locks, create keys for the locks, and be sure not to put a key in a locked room (unless you're sadistic). 


A Few WORDS ABOUT ISOMETRIC MAZES 


W hen you generated your maze, it was rectangular, not isometric. T hus, the changeover requires some 
thought. | think that diamond maps are the best suited for mazes, since you simply have to shift the 
directions a little bit, making MAZE_NORTH actually point to the northwest when you create the map. 
T his is just my opinion, though. 


W hen taking a maze and converting it to an isometric map, you might want to use a sort of "tile tem- 
plate” | have not discussed these prior to now. A tile template is just a mini-tilemap representing perhaps 
a room or corridor. Т he tile template contains all the information about what background tile goes where 
and what foreground images go where, but it's set up in such a way that they can be put together like a 
puzzle and result in a reasonably rich-looking tilenap, even if it's based on a generic maze. 


GROWING CONTINENTS 


М azes are rather on the microscopic end of world building. O n the other end of things is growing 
continents, where you build entire planets full of map information. It’s a pretty simple algorithm. 


| generally like to begin my continent building by starting with a blank map, which represents unending 
ocean. | then place а number of “seed” pixels to represent land. From there, | randomly seek out ocean 
squares that exist next to land squares, and | place new land pixels there until | have as many land areas as 
| desire (usually, | specify this as a percentage of the map). 


Simple enough, right? 150Н ех22 2 has an example of code that does this. Н eres a simple breakdown of 
how it works: start with a blank blue (representing ocean) bitmap and place а number of seed dots con- 
sisting of pixels and lines in green (representing land). After you place the seeds, randomly select ocean 
squares next to land squares and make them into land squares. In this manner, you grow continents. 


//map constants 

const int MAPWIDTH=320; 
const int MAPHEIGHT=320; 
const int MAPSEEDS=100; 
const int LANDPERC=30; 


T hese are а few constants used for generating the continents. MAPWIDTH and MAPHEIGHT are sef-explanato- 
ry. MAPSEEDS is the number of seeds with which you start the map. LANDPERC Is the percentage of the map 
you want to have as land. 
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int x,y,count; 

//pick random location 
x=rand()%MAPWIDTH; 
y-rand()ZMAPHEIGHT; 

//move to the location 
MoveToEx(gdicMap,x,y, NULL) ; 


You start in a random location (x,y) and work from there T he method | came up with for this example 
uses both single pixels and line segments. If a line segment is chosen first, it needs to have a starting point 
other than (0,0). 


//place the seeds 
for(count=0;count<MAPSEEDS;count++) 
{ 
if((rand()%4)==0) 
{ 
//pick random location 
x=rand()%MAPWIDTH; 
y=rand()%MAPHEIGHT; 
//move to the location 
MoveToEx(gdicMap,x,y,NULL); 
SetPixelV(gdicMap,x,y,RGB(0,255,0)); 
} 


On aonein-four chance, the generator will start a new continent with a single pixel. T hat's what this little 
bit of code does: 


else 

{ 
//line to that location 
x=xtrand()%50-25; 
у-уғгапа()%50-25; 
LineTo(gdicMap,x,y); 


} 


Ona three in-four chance, the generator continues with the same continent, drawing a short line segment. 
Line segments make for better continents than single pixels. 


} 
//place the rest of the land 
for (count=0;count<MAPWIDTH*MAPHETGHT*LANDPERC/100;count++) 
{ 
//pick a coord next to a land square 
bool found=false; 
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do 


//pick random place 

x=rand()%MAPWIDTH; 

y-rand()ZMAPHEIGHT; 

//ensure the area is water 
if(GetPixel(gdicMap,x,y)!-RGB(0,0,255)) continue; 


Finally, after you have placed all the map seeds, it is time to place the rest of the land. First, choose a ran- 
dom location, and you make sure that this location has a water (blue) pixel there You dont want to place 
land pixels twice in the same spot! 


//ensure it is next to another land area 

if(x>=0 && GetPixel(gdicMap,x-1,y)==RGB(0,255,0)) found=true; 

if (x<(MAPWIDTH-1) && GetPixel(gdicMap,x+1,y)==RGB(0,255,0)) 
found=true; 

if(y>=0 && GetPixel(gdicMap,x,y-1)==RGB(0,255,0)) found=true; 

if (y<(MAPHEIGHT-1) && GetPixel(gdicMap,x,y*1)--RGB(0,255,0)) 
found=true; 


T he second rule is that the pixel in question has to be next to an existing land square (hence, you have the 
seed pixels to start with). T hese lines check for a neighbor that is green: 


//keep looping until you find an appropriate space 
}while(! found); 

//place pixel 

SetPixelV(gdicMap,x,y,RGB(0,255,0)); 
SendMessage(hWndMain,WM PAINT,0,0); 


Finally, set the pixel, and continue looping until all the pixels are set. T his method places 
MAPWIDTH*MAPHEIGHT*LANDPERC/100 pixels, plus an insignificant number of pixels that were in the seeds. 


After you have grown the continents, you need to variegate and populate them just like a maze. You might 
want to place rivers, forests, mountain ranges, deserts, and so on. Just try to be coherent, and dont put 
ocean right next to mountains. U nfortunately, since there are so many different types of games in which 
you would want to generate continents, it's impossibleto give decent advice as to how to populate them. 


SUMMARY 


T here are many more ways to generate worlds besides continent growing and maze generation, but the best 
method is always the one you come up with on your own. U se the maze generator or the continent grower 
as a base for your own methods. World generation isnt very scientific; it's very much trial and error. 
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5 you have seen over the course of this book, the graphical aspect of making isometric games is 
quite easy once you've got the hang of the algorithms behind it. U nfortunately, spiffy graphics, 
stereo sound, an intuitive user interface, and a shiny box do not a game make. 


In this age of multiplayer "death match" and “capture the flag” games, artifidal intdlignce (Al) seems to have 
gone by the wayside. M any games now ship with only a minimal solo play component, and this, in my 
opinion, is just wrong. М ultiplay is a great thing, and nowadays it is virtually a required feature of games, 
but it should not be the whole game A good game should bea challenge, period, whether youre playing 
against other players or playing against the computer. If this is not the case, you have failed. H arsh words, 
yes, but | mean them. 


T his chapter can only touch upon a few relatively minor aspects of Al, since many voluminous books have 
been written on the topic of AI in general. In the modern day, we cannot hopeto put the computer on 
par with an experienced player. T he best we can do is fake it. l'm mainly going to discuss pathfinding, and 
I'll touch on a couple of other Al topics. T he problem is that many different genres of game fall under the 
isometric umbrella, and | cant sufficiently cover all of them. If you want, go ahead and email me, and 1'|! 
give you a few good suggestions for reading about Al. 


WHAT 15 Е? 


Al, as just stated, is artificial intelligence. A good definition cannot be found, because the great thinkers are 
having a hard time deciding what “intelligence” means. T he commonly understood meaning of Al is making 
the computer think, which will do just fine for us. 


Wedo not yet understand the inner workings of the human brain, which means we dont actually know 
how thinking takes place. So, you arent really going to make the computer think. Instead, you will make it 
look like the computer is thinking, and if you do a good job, no one will be the wiser. 


REALLY SIMPLE НІ STUFF 
W ell start out really simple and then get more complicated as we go. T hat way, you wont have to digest 
any seriously technical details up front. 


Take a look at Figure 23.1, which shows a game board (8x8, much like a checkerboard) with two pieces, 
each shaded differently to show that the pieces are on different teams. 
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Figure 23.1 
A board with tokens 


In the absence of obstacles, making the lighter piece move toward the darker piece is simple. As human 
beings, we can simply eyeball it and move the lighter piece diagonally up and to the left, closing the gap, as 
shown in Figure 23.2. 


Figure 23.2 
Closing the gap 


T his is a simple matter for us, because we have long been accustomed to such tasks. A computer, on the 
other hand, has no way of "eyeballing" the situation. It must rdy on mathematical calculations. It is your 
job to teach the machine to do this very simple task. 
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T his example is elementary and very easy to solve, which is why | picked it. Since you can move іп any of 
the eight directions, you know that you can increase or decrease x and/ or y by 1, or not change it at all, 
so that making a move leaves the piece on any one of nine squares (the square it currently occupies and 
all neighbors). 


So, if you assigned numbers to the grid and made the light piece be at (Ix,ly) and the dark piece be at 
(dx,dy), you could use the following code to determine what move to make: 


//chase algorithm 
if(lx!-dx)//check for non-matching x 
{ 
if (1x>dx) 
{ 
//higher x, so decrease it 
1x-; 


//lower x, so increase it 
lx; 
} 


if(ly!=dy)//check for non-matching y 
{ 
if (ly>dy) 
{ 
//higher y, so decrease 
ly-; 


// lower y, so increase 
1у++; 


Voila! After a certain number of steps, the light piece would quickly catch the dark piece T his is a really 
basic d'ase algorithm. It works effectively only in the simplest of cases. 


W hile were here, let's take a quick look at a really basic evade algorithm, which is the exact opposite of 
the chase algorithm. If you switch around the ++s and - -s of the chase algorithm, you've now got an 
algorithm that will run away as fast as it can. 
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//chase algorithm 
if(lxl!-dx)//check for non-matching x 
{ 


if (1x>dx) 

{ 
//higher x, so increase it 
1х++; 


//lower x, so decrease it 
1х-; 


} 
if(ly!=dy)//check for non-matching y 
{ 
if(ly>dy) 
{ 
/[higher у, so increase 
1у++; 


//Томег у, so decrease 
ly-; 


Both the chase and evade algorithms are quite simple, so they're only well-suited to very simple situations. 
So, if the board were made more complicated, to include blocked squares where pieces cannot move, 
something similar to Figure 23.3 might result. 
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Figure 23.3 


Where the simple 
chase algorithm fails 


Figure 23.3 has five blocked squares. If the light piece tries to use the simple chase algorithm, it will be 
stuck after two moves (assuming, of course, that the dark piece remains stationary). 


W hat the light piece should do is go around the obstacle, as shown in Figure 23.4. T he path in Figure 23.4 
isnt the only one that the light piece could take, but it'll do for now. N aturally, in order to make the light 
piece catch the dark piece, you need a fancier algorithm than just the simple chase algorithm. 


Figure 23.4 


Evading the obstacle 


e————. 
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MORE ADVANCED FPHTHFINDING 
FALGORITHM™ 


A lot of Al terms exist that | dont use. T he algorithm I'm about to show you is an implementation of 
what is called A* (A-star) pathfinding. К ather than cluttering your mind (and these pages) with a lot of Al 
mumbo-jumbo, |’m just going to show you how to do decent pathfinding without the terminology, which 
you dont need anyway. 


First, you need a 2D array of integers (or any old type, really; it just has to be large enough to contain 
distance values). T he array, of course, has to have the same dimensions as the game board (8x8 in the case 
of the figures). 


To start, set all of the array’s cells to a value of - 1. - 1 means that the square has not been tested yet. For 
any “blocked” square, put a number so large as to not bea possible distance. In this case, 255 is a good 
value. Finally, at the destination (meaning the dark pieces location), place a 0. T he current board is 
shown in Figure 23.5. 


Figure 23.5 
1 1 1 1 -1 1 1 1 RA 
Initial state of the array 
-1 9 -1 1 1 1 1 1 
1 -1 1 -1 1 
1 -1 1 -1 1 
-1 -1 1 -1 1 
-1 -1 1 -1 1 1 1 1 
1 1 -1 1 -1 -1 -1 -1 
1 1 -1 1 -1 -1 -1 1 


N ext you will perform a number of passes over the array. Each pass will involve a couple of steps. 
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ETEF 1: SCAN ARRAY FOR CELLS 
ADJACENT TO CELLS WITH KNOWN 
DISTANCES 

T his step may need a little clarification. You know a few things about the board at this point. T he cell con- 
taining а 0 is the goal. N aturally, the cell with the goal is no distance from the goal (duh!). T his is what | 
call a known distance. Based on this, naturally any of the cells adjacent to the cell with a 0 in it would have 
a distance of 1. I'm getting slightly ahead here, but it's pretty plain to see. 

T he goal of Step 1 15 to determine the cells next to a "known" distance Т his can be stored in a 2D 
boolean array where true means an adjacent cell and false means a nonadjacent square. In the figures, l'II just 
highlight the squares. 


After the first step of the first pass, the result looks like Figure 23.6. N ote that the 255 squares are not 
considered known distances, and that only squares with a value of - 1 are marked. 


Figure 23.6 
Step 1 of the first pass 


-1 -1 -1 1 -1 
1 -1 -1 1 -1 
1 -1 1 -1 1 
1 1 -1 -1 1 1 -1 1 
1 1 1 -1 -1 1 1 1 
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N ow for something important about the first step of а pass: № no squares get marked in the first step, the 
pathfinding is over, even if there are still values of - 1 elsewhere in the array. If no squares were marked, no 
adjacent squares were found, and a path might be impossible 


STEP E: Give ADJACENT SQUARES A 
1KNOUVIN DISTANCE VALUE 


N ext, you replace all the - 1s that have been highlighted with a value. For the first pass, this value is 1, for 
the second pass, 2, and so on.T he first pass would look like Figure 23.7. 


Figure 23.7 
1 1 1 1 -1 -1 1 -1 m 

Giving values to 
1 1 а EI а а а marked squares 
1 1 1 1 -1 
1 -1 1 1 -1 
-1 -1 1 1 -1 
-1 -1 1 1 -1 1 -1 -1 
-1 -1 1 -1 1 1 1 1 
-1 -1 1 -1 1 1 1 1 


T his process is repeated until one of the following occurs: 


= Step 1 finds no adjacent squares. 
= Thecell of origin (the location of the light piece) gets filled in. 


| almost added a third condition— when the board is full— but in that condition, Step 1 would find no 
adjacent squares in the next pass, so it is redundant. 


WHA AEN 1771S ALL DONE 


Figure 23.8 shows the board with a completed pathfinding array. N ote that the light piece has a value of 
7. In order for the light piece to capture the dark piece, the light piece must move to lower-valued 
squares— from 7 to 6, 6 to 5, 5 to 4, 4 to 3, 3 to 2, 2 to 1, and finally 1 to 0— until the dark piece has 
been caught! 
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Figure 23.8 


A completed array 


1 1 1 5 6 
2 2 2 6 6 
3 3 3 7 7 


All in all, this is a beautiful algorithm. It will always get the piece to where you want it to go, or it will let 
you know if such a move is impossible. 


N ow, if | were to tell you that each of the squares in the array is called a node and that you were making 
links between the nodes into a search tree in order to do pathfinding, and that you have just learned how 
A* pathfinding works, youd look at me like! was nuts. It's true though. T his algorithm is an implementa- 
tion of A*, as | stated earlier, in a more practical form. (Since a grid of tiles is easier to work with than the 
real world, the nodes become more discrete) 


IsoH ех23 1.срр has an implementation of this pathfinding algorithm. M ost of this example is concerned 
with showing the graphical representation of the map. T he actual pathfinding is done in a function called 
FindPath.T his is a rather simple example Two types of areas exist— one that you can walk on, and one 
that you cannot. In a real application, this would be more complicated, with different types of terrain 
having different path costs. H owever, the simplest case (this one) is easiest to understand, and once you 
understand it, extending it to deal with more complicated maps is pretty easy. Figure 23.9 shows the 
program output. 
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Figure 23.9 
Output of ІѕоН ех23 1.cpp 


void FindPath()//find the path 
{ 
POINT ptStart; 
POINT ptEnd; 
POINT ptPath; 
ptStart.x--1; 
ptEnd.x--1; 
int x; 


int y; 

int nx; 

int ny; 

bool found; 
int lowvalue; 


First, you need a number of variables to make this work, including starting and ending positions (ptstart 
and репа), a few looping variables (x,y), some temporary variables for x,y coordinates (nx,ny), and some 
testing vars (found and 1owva1ue). T hex part of ptStart and руЕпа is set to - 1, because you first 
check that a starting point and an ending point exist in the map. If they dont, there is no need to continue 
with finding the path. 


//find the start 
for (x=0;x<MAPWIDTH; x++) 
{ 


for(y=0;y<MAPHEIGHT; y++) 
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//check for the start 


if (Maplx]Ly ]J==TILESTART ) 
{ 


ptStart.x=x; 
ptStart.y=y; 


Lo and behold, this code snippet attempts to find the starting point. If one is found, its position is 
placed in ptStart. 
//find the end 
for (x=0;x<MAPWIDTH; х++) 
{ 
for(y=0:y<MAPHEIGHT; у++) 
{ 
//check for the end 
if (MapCx]Ly]J==TILEEND) 
{ 
ptEnd.xex; 
ptEnd.y=y; 


} 
//if no start or end, exit function 
if(ptStart.x---1 || ptEnd.x---1) return; 


T he following code is the same as the preceding, except that this time you are seeking the ending point. 
After you have looked for both, you check to see whether they exist (that is, that the x values of the 
POINTS In which they are stored is not - 1). 
//fill out the path array 
for (x=0;x<MAPWIDTH; x++) 
{ 
for(y-0; y<MAPHEIGHT ; у++) 
{ 
switch(MapEx]LyJ) 
{ 
case TILESTART://place а 0 at the start 
{ 
MapPath[x]1Ly1-0; 


PATHFINDING AND AI  Э ҒЖ/ 


}break; 
case TILEBLOCK://place a 999 at any blocks 
{ 


MapPath[x]Ly1-999; 
}break; 
case TILEEMPTY://if empty, place a -1 
{ 
MapPath[x]lLyl--1; 
}break; 
default://anything else, place а -1 
{ 
MapPath[x]Lyl--1; 
}break; 


} 


An array called MapPath (a global array) is where you build the pathfinding information. You start 
by replacing everything with a - 1 (passable square), a 0 (starting position) , or a 999 (a blocked, 
unpassable area). 


//scan for pathable tiles 
do 
{ 


//haven’t found one yet 
found=false; 

//scan the map 

for (x=0;x<MAPWIDTH; x++) 
{ 


for (y=0;y<MAPHEIGHT ; у++) 
{ 
MapMark[x]Lyl-false; 


You now check for tiles to which you can determine paths. For this, you use another global array, мармагк. 
T his array contains true at a place where you can calculate the path cost and false in a 
place where you cannot. To start out, set it to false, thus erasing whatever happened before. 


//make sure this is a -1 square 
if (MapPathLx]Ly]==-1) 
{ 


Ensure that the MapPath array has а - 1 at the position you are checking. If it does not, it is ether a 
blocked square or one whose path has already been calculated (and you dont want to calculate it twicel). 


EEE ISOMETRIC GAME PROGRAMMING WITH, DIRECTX 7,0 


//scan the neighbors 
for (nx=x-1;nx<=x+1;nx++) 


{ 


Ғог(пу=у -1; пу<=у+1; пу++) 
{ 
//make sure the neighbor 
//is on the map 
if(nx»-0 && пу>-0 && nx<MAPWIDTH 
&& ny<MAPHEIGHT && 
| (пх==х && пу==у)) 
{ 
//check against negatives 
//and 999 
if(MapPath[nx][ny]>=0 && 
MapPath[nx][ny]1!-999) 
{ 


№ ext, you scan the neighbors of this location. You are looking for a nonnegative, non-999 value, indicating 
that this position is next to a position that has already been calculated, which means that this position can 
now be calculated. 


//mark the map 
MapMarkLxJLy]=true; 
//mark it as found 
found=true; 


If you find such a neighbor, you mark it as true іп the MapMark array and also set the local variable found 
to true, meaning that you have found at least one. (W hen found stops being true, pathfinding is over, 
whether or not the entire map has been calculated.) 


//now scan the marks 

for (x=0;x<MAPWIDTH;x++) 

{ 
for (y=0;y<MAPHEIGHT; у++) 
{ 
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//if this square is marked 
if(MapMarkEx]ILy1) 
{ 


//set low value very high 
lowvalue=999; 


It's time to loop again. T his time, you're checking for marked squares. If one is found, you know that you 
can calculate the path. H owever, you want to step from this square to the square next to it with the lowest 
path cost, so you need to loop through all the neighbors and check those path costs. 


//\oop through neighbors 
for (nx=x-1;nx<=xt1;nx++) 
{ 
Ғог(пу=у -1; пу<=у+1; пу++) 
{ 
//make sure the neighbor 
//is on the map 
if(nx>=0 && пу>-0 && nx<MAPWIDTH 
&& ny<MAPHEIGHT ) 
{ 
if(MapPath[nx][ny 152-0) 
//must be a nonnegative 
//value 
{ 


//assign the value 
//if it is lower 
if(MapPath[nx][ny]«4 

lowvalue) 
lowvalue-MapPath[nx] 
[ny]; 


T his loops through the neighbors and checks their values against 10wva1ue. If the value at that square is 
lower, 1owvalue becomes that new value. 


//assign the value to the path map 
MapPathEx]Ly]J=lowvalue+l; 


ЕЕ: ISOMETRIC GAME PROGRAMMING WITH, DIRECTX 7,0 


} 
while( found); 


Because you have found the lowest-valued neighbor, assign that value + 1 to the MapPath array at the posi- 
tion in question, and continue looping, Т he last line, whi 1e( found), concerns the state of the found vari- 
able, which | discussed briefly earlier. 


N ow you have as complete a picture of the board as you can. All squares that can be reached from the 
starting point have been assigned values. W hat you need to do now is start at the ending point, make sure 
that it has a path value, and work backwards. 


//done with pathfinding 
//check to see that ptEnd has found a path 
if(MapPath[ptEnd.x][ptEnd.y]1!7-1) 
{ 
//start the path 
ptPath=ptEnd; 
//take the value from the map 
lowvalue-MapPath[ptEnd.x][ptEnd.y]; 


You recycle the 1 owva1ue variable here, this time keeping track of the current position's path cost. 
W ith each iteration, continue to seek a lower value. 


while(lowvalue»0) 
{ 
found=false; 
do 
{ 
do 


//pick a random neighbor 

nx=rand()%3-1; 

ny=rand()%3-1; 
Імһі1е((пх--0 && ny==0) || (ptPath.x+nx)<0 | | 
(ptPath.xt+nx)>=MAPWIDTH || (ptPath.y+ny)<0 || 
(ptPath.y+ny )>=MAPHEIGHT) ; 


T his bit of code picks a random direction of movement, making sure that the movement is not 0 and 
that it does not go outside the map's boundaries. Set found to false again, because you might need to 
check several directions before you find one that has a lower pathing cost. 


//check to see if the value is lower 
if(MapPath[ptPath.xtnx][{ptPath.ytny ]<lowvalue) 
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// found! 

found=true; 

//set tile to path tile 
Map[ptPath.x][ptPath.y]=TILEPATH; 
//move the path 

ptPath.x+=nx; 

ptPath.yt=ny; 
lowvalue-MapPath[ptPath.x][ptPath.y]; 


} 
} 
while(!found); 


If you have indeed struck gold, found is set to true, place а little marker for the path, move in that 
direction, and decrease the value of 1owva1ue. If you have not found a suitable move, continue checking 
until you do. 


} 
//replace the end tile 
MapLptEnd.x]{ptEnd.y]J=TILEEND; 


} 


Because of the method | used to place markers on the path, | needed to replace the end marker when 
| was done. T hat's all that this final line does. And that's all there is to a pathfinding function. If | 
werent actually marking the path, it wouldnt be quite as long. 


MAKING FPATHFINDING USEFUL 


Although the algorithm for finding a path can become quite complicated (much more complicated than it 
has been in the simple case | ve shown here), it is by far the easiest part of Al. It is easy to figure out how 
to get from point A to point B in the shortest path possible T he hard part is deciding to which point B 
you want to go. T hat is the "true" Al aspect. By comparison, finding a path is child's play. 


For example, let's say you're writing an RPG of some sort (with monsters and the player characters, 
treasure, swords, magic spells, the whole bit). You can go the simple route and have all the monsters head 
for the player characters, but that's not much of an Al. You might as well be playing б auntlé. 


Instead, you want to make your monsters work as a team. You might have some monsters maneuver around 
so that the player's escape is blocked, and you might place others in a position to fire arrows or cast spells 
at the player. Also, if this is a party-based АРС in which the player controls a group of characters instead 
of just one, you want your monsters to intelligently decide on targets, meaning that you want them to take 
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out the archers and spell casters first and then slug it out toe to toe with the rest. A pathfinding algorithm 
can help with a lot of this. It can figure out how to get a monster from one place to another, but it cant 
decide where to send them. In addition, you need your monsters to be able to deal with the unforeseen, 
such as when one of their comrades is killed and the plan has to be changed. T his is the real Al. 


H eres another example, for turn-based strategy. Т he players (both human and computer) have a number 
of units at their disposal. Н owever, different units are better suited to different roles, such as attack, 
defense, scouting, transporting, and so on. 


Fast-moving horse units are good for exploring new territory, so you use the pathfinding algorithm to find 
a square next to a previously unexplored square and send the explorer in that direction. Attack units need 
to be able to find their way to enemy cities or move to ward off invaders. T he uses of pathfinding here are 
quite clear. Transport units need to be able to meet up with the units they will be transporting and then 
get those units where they need to go. 


As you сап see, even after you can find the path from A to B, the work is anything but done T here is a lot 
to Al besides algorithms. 


SUMMARY 


U nfortunately, | can only vaguely touch on artificial intelligence, with enphasis on pathfinding, since its 
need is so common in isometric games. Please forgive me. M any brilliant people have written entire 
volumes on the nature of Al and the methodology for achieving a semblance of intellect. | am mainly 

a graphics programmer. l'm not on par with people who make AI their life study. 

Still, | hope this chapter at least got you thinking. Artificial intelligence is definitely an area that is not 
written in stone. N ew theories are coming to the front all the time. As Andre L aM othe says, the next great 
leap forward in computer technology will come from studies in Al, and nowhere ese 
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hroughout this book, one detail may have been gnawing at you. U p until now, | ve been using 
DirectD raw to do all of the rendering. Admittedly, we've wrapped it up pretty well with the 
CTileSet dass and the |soH exCore components, but the fact is that it's still D irectD raw, and it is 
from DirectX 7.0, not DirectX 8.0, which was the latest version of DirectX at the time of 
this book's publication. 


W hy am | using the (obviously inferior) version 7.0 rather than the new and spiffy 8.0?T he answer is a 
bit involved and comes in two flavors. | have actual reasons for using 7.0 rather than 8.0, and | also have 
some cop-outs. ІЛІ give you the cop-outs first: 


= Cop-out # 1. 115 easier to learn a 2D API like D irectD raw, which DirectX 8.0 doesnt have (8.0 incorporates 
DirectD raw and Direct3D (D3D) into a single part of the API). 

= Cop-out #2. W hen DirectX 8.0 came out, | had less than two months until the book had to be complete, 
which is insufficient time to update all the text and code adequately. 

= Cop-out #3. DirectX is backward-compatible 

= Cop-out #4.T he book is mainly concerned with algorithms, not 2D or 3D APIs, and the techniques apply 
no matter what you are using to render. 


Ном true or false are these cop-outs?W ell, #1 is true to an extent. Learning а 3D API is a bit more 
involved than learning a 2D API, and isometric algorithms are primarily 2D in nature, and the extra math 
is unnecessary. Also, D irectD raw and D3D were merged in DirectX 8.0. 


Similarly, cop-out #2 is true, sort of. | was not on the DirectX 8.0 beta program, so 8.0 became available 
to meat the same moment it became available to all of the other developers in the world. W hen DX8 
came out, | had two choices: Either stick with 7, or update everything (dozens of sample programs and 
hundreds of pages of text). 


Cop-out #3 is also true. DirectX is backward-compatible and promises to be so forever (forever meaning 
until M icrosoft doesnt feel like it anymore). You can still use the old version 7 interfaces. 


T he final cop-out comes closest to the truth. T he isometric algorithms in this book can be applied to any 
platform and any API. | ve done isometric games that use Ср, D irectD raw, D irect3D, and even some old 
DOS stuff. T he methodology is the same no matter what. 


N ow the truth: M y reason for using DirectX 7.0 instead of DirectX 8.0 is that in DirectX 8.0, there is no 
real support for traditional 2D graphics. You can still do 2D graphics with D irectX 8.0, as you will see in 
a moment, but not in the traditional manner, and doing graphics the way you have been doing them thus 
far is a pain in the butt in D X8 and would be highly confusing (for both of us). 
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N ow that | have admitted this, let's move on. T his chapter is an introduction to D 3D (version 7.0). 
Because of the nature of isometric games and the algorithms behind them, you wont be exploring most of 
the D 3D API, because most of it is useless to you. Instead, you will use D3D as a 2D renderer, and these 
algorithms, with only slight modification, can be applied with ease. 


DiIRECTSD AS A ZD RENDERER 


It might seem strange to read this heading. T he word “3D” is right at the end of “D irect3D, and to use 
it as a 2D renderer seems far-fetched and a gross misuse of power. Far-fetched, no, but a gross misuse, yes! 
Н owever, that is a good thing. | will explain. 


3D Games (AND XD AP 1s) ARE STILL 
ONLY 20 


Yes, they look 3D.T here is perspective correction for distance. T here is the illusion of lighting, and 
various other factors that make the image appear as though it were 3D. Y our screen, however, is still flat 
(or slightly curved, if you're using a CRT and want to get technical about it) and is, for all intents and 
purposes, strictly 2D. H ence, anything drawn on the screen can be nothing other than 2D, at least until 
science invents some sort of holographic projector that will allow true 3D. 


So, the image on your screen as you play a 3D game is merely a projection of that scene in 2D, giving 
the illusion of 3D. 


How DIRecTSD WORKS 


T his is probably going to be the most simplistic explanation of the workings of Direct3D ever written, 
but at its core, it is true: Direct3D does nothing more than render triangles on the screen. 


№ aturally, it’s a little more involved than that. Т he triangles can be textured with a pattern of bits stored 
in a DirectD raw surface, and the triangles can be given the illusion of lighting and can be blended translu- 
cently. Even multiple textures can be used, merged by different means to give a different look. Direct3D 
can also take care of the complex math required to project a 3D scene onto your 2D screen, but it doesnt 
require that you make use of that ability. 


So, youre still just drawing triangles on the screen, and two-dimensional triangles at that (triangles, by their 
nature, being 2D). If all you are doing is rendering triangles, doing 2D graphics is very easy. То make a 
rectangle, you need only two triangles, as shown in Figure 24.1. Similarly, you can split an isometric tile in 
half (either lengthwise or widthwise), and you again have two triangles. 
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Figure 24.1 


Using triangles to 
make a rectangle 


Triangle #1 


DireECTSD BASICS 


T his next section will seem like a “back to basics” section, because l'Il discuss the innards of D irectX , 
which you havent really dealt with since the creation of cTi1eset many chapters ago. 


In Direct3D (version 7.0, at least), you will be primarily concerned with two new objects— 10irect307 
(which is akin to the 1DirectDraw7 object) and 1Direct3DDevice7 (similar in function to 
101 rectDrawSurface7). 


First, in order to have your applications use D irect3D, you must add a new library file and a new header. 
T he library is named d3dim.lib, and you add it to your project in the same manner as you have added 
ddraw.lib and dxguid.lib all along. T he header is named d3d.h, and you simply include it in any file that 
needs to use D irect3D. 


IckY СОМ STUFF 


Before you do anything else related to Direct3D, you must first have an 1Direct3D7 object and store a 
pointer to it in an LPDIRECT307 variable. In order to get this pointer you must do icky COM stuff. 


Every DirectX component has three member functions: AddRef, QueryInterface, and Release. Youre 
already familiar with Release, since you use it all the time to clean up objects. AddRef is a way to man- 
ually add a reference to an object so that it does not get deleted at an inappropriate time (AddRef remains 
largely unused). QueryInterface, however, is a little trickier to explain, and it just so happens to be the 
member function you need to get started with Direct3D. 
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| wont go into the subtleties of the COM interface stuff. It takes a lot of explanation, it's really boring, 
and you probably dont саге You just want to make use of D irect3D, and and you want to do it now. | 
understand and will comply. 


Н eres the magic line that will give you a pointer to an 1Direct307 object: 


//lpdd is an LPDIRECTDRAW/ variable 
//\pd3d is an LPDIRECT3D7 variable 
lpdd-»QueryInterface(IID IDirect3D7,(void**)&lpd3d); 


| suppose а little explanation couldnt hurt. T he first parameter of QueryInterface is а REFIID, Or a 
reference to an interface identifier. U se a different one іп DirectDrawCreateEx to make your 
IDirectDraw7 Object. 


T he software component that you are used to thinking of as an 1DirectDraw7 object is more than it 
seems. Н idden within it is ап 1Direct3D7 object. T he best analogy would be the layers of an onion. 
You simply use QueryInterface to bring the other layers to light. 


Once you've got your 1Direct3D7 object, all you need to do is store it in a variable somewhere, and dont 
forget to release it later. T his is all theicky COM stuff you need to do for now. 


SURFACE CREATION 


Since you're now using Direct3D, you have to make some subtle modifications to the way in which your 
rendering surfaces (the primary surface and the back buffer) are created. You have to let DirectX know 
that you intend to render using 3D methods onto these surfaces. T he manner in which you do this 
involves a slight change to the DpSURFACEDESC2 Structure. 


T he following code was taken from D D Funcs.cpp. It sets up a primary surface with a given number 
of back buffers. 


//set up a DDSD for a primary surface, with any number of back buffers 
void DDSD_PrimarySurfaceWBackBuffer(DDSURFACEDESC2* pddsd, DWORD 
dwBackBufferCount ) 

{ 


//clean out the ddsd 

DDSD_Clear(pddsd); 

//set flags 

pddsd->dwFlags=DDSD_CAPS | DDSD_BACKBUFFERCOUNT; 

//set caps 

pddsd->ddsCaps.dwCaps=DDSCAPS_PRIMARYSURFACE | DDSCAPS_COMPLEX | 
DDSCAPS_FLIP; 

//set back buffer count 

pddsd->dwBackBuf ferCount=dwBackBufferCount ; 
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And now heres the same function, rewritten so that the primary surface can be used with D irect3D. 


//set up a DDSD for a primary surface, with any number of back buffers 
void DDSD 3DPrimarySurfaceWBackBuffer(DDSURFACEDESC2* pddsd, DWORD 
dwBackBufferCount) 

{ 


//clean out the ddsd 

DDSD_Clear(pddsd); 

//set flags 

pddsd->dwFlags=DDSD_CAPS | DDSD_BACKBUFFERCOUNT; 

//set caps 

pddsd->ddsCaps.dwCaps=DDSCAPS_PRIMARYSURFACE | DDSCAPS_COMPLEX | 
DDSCAPS_FLIP | DDSCAPS_3DDEVICE; 

//set back buffer count 

pddsd->dwBackBuf ferCount=dwBackBufferCount; 


Since the change is not obvious, | made it bold. All you need to do is add an extra flag to the surface's 
ddsC aps.dwCaps, and you are ready to use К as a 3D device It's just that simple. 


Similarly, if you intend to render onto the back buffer, you need to place the same flag into its 005САР52 
structure, as you did with the primary surface. D ont worry too much. You'll make a small set of functions 
to help you out in this regard. 


CREATING A DEVICE 


O nce you've got your 1Direct3D7 object, and you've set up a surface to be used as the rendering 
target, it's time to make the IDirect3DDevice7 object. To do so, use IDirect3D7'S CreateDevice 
member function. 


HRESULT IDirect3D7::CreateDevice( 
REFCLSID rclsid, 
LPDIRECTDRAWSURFACE7 1pDDS, 
LPDIRECT3DDEVICE7 * 1plpD3DDevice, 


T he rcisid parameter is a REFCLSID, which is like a REFIID, which is in turn a GU ID. Dont ask me 
why M icrosoft felt it needed so many names for the same thing! M ore about this parameter a little 
later. T he 1рорѕ parameter is the surface you want to use as the rendering target for this device. Finally, 
1p1pD3DDevice iS a pointer to a pointer to the device to be created. D evices are created іп this way, much 
like D irectD raw surfaces are. 
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So, what of rcisid?Well, this is a class identifier (GUID) telling Direct3D which 3D device to use. 
Depending on your video card, you might have several flavors available to you. In DirectX 7.0, there are 
four flavors of device 110. IDirect3DTnLHalDevice, 1ID_IDirect3DHALDevice, 
1ID_IDirect3DMMXDevice, and IID IDirect3DRGBDevice.T hese аге listed in decreasing order of 
desirability and speed. 


Ideally, you have aT nLH al device, which is super fast. It handles texturing and lighting in hardware and 
tends to have the best hardware capabilities. N ext is the H AL device, which is usually pretty good, but not 
nearly as good as theT nL H al. T his is followed by the M M X device, which has multimedia extensions, etc., 
etc. And last and certainly least is the RGB device, which is software emulation and can always be used. 

It is there mainly for maximum compatibility, and it is darned slow! 


So, which one to pick? It would be nice to make use of theT nL, but not all machines have one. Same 
thing for HAL and M M X. You could use the RGB device, but that would bean insult to the machines 
that have a much greater 3D acceleration capability. W hat you must do, then, is use the best device of 
the machine on which that the program is running, defaulting to the RGB device only when nothing 
else is available. 


H ow do you do that?T here aretwo ways— the "professional" way, which enumerates devices, and the 
"hack" way, which is simpler, shorter, and does the exact same thing as the professional way. 


So, here's the hack function to give you a 3D devicefor D 3D: 


LPDIRECT3DDEVICE7 CreateD3DDevice(LPDIRECT3D7 lpd3d,LPDIRECTDRAWSURFACE7 lpdds) 
{ 


LPDIRECT3DDEVICE7 lpd3ddev; 
//try to make a TnL device 
if(FAILED(Tpd3d-»CreateDevice(IID IDirect3DTnLHalDevice,lpdds,&lpd3ddev))) 
{ 
//no TnL; try for HAL 
if (FATLED(1pd3d- 
»CreateDevice(IID IDirect3DHALDevice,lpdds,&lpad3ddev))) 
{ 


//no HAL; try for MMX 
if (FAILED( 1 pd3d->CreateDevice(IID_IDirect3DMMXDevice, 
lpdds,&lpd3ddev))) 


{ 
//no MMX; try for RGB 
if (FAILED( 1 pd3d->CreateDevice(IID_IDirect3DRGBDevice, 
lpdds,&lpd3ddev))) 
{ 
//no RGB; so return NULL 
|] pd3ddev=NULL; 
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} 


} 
//return the new device 
return(1pd3ddev); 


} 


T his is a pretty simple function. You try to make the best device you can, and failing that, you fall back 
to an inferior device, finally falling to an RGB. If you cant even get an RGB, something else is probably 
wrong, so the function returns NULL. Later, during program cleanup, you release the device just like any 
other DirectX object. 


MAKING A VIEWPORT 


Youve got the 1Direct307 object, and youve created your 1Direct3DDevice. Youre most of the way 
set up to start rendering. O ne last thing stands in your way: the viewport. 


In D3D, you dont have to render to the entire target surface. You can instead render to only a portion of 
it, and you can choose which portion. То do so, fill out a 030/1ҒиРОвТ7 structure. 


typedef struct _D3DVIEWPORT/{ 


DWORD амХ; 
DWORD амУ; 
DWORD dwWidth; 
DWORD dwHeight; 


D3DVALUE dvMinZ; 
D3DVALUE dvMaxZ; 
} D3DVIEWPORT7, *LPD3DVIEWPORT7 


Table 24.1 explains the members of D3Dv1EwPoRT7 and their purposes. 
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Table 24.1 Members of D3DVIEW PORT7 


Member Purpose 

dwX The left edge pixel coordinate of the viewport 
dwY The top edge pixel coordinate of the viewport 
dwWidth W idth of the viewport in pixels 

dwHeight Height of the viewport in pixels 

dvMinZ Minimum z value (see the next paragraph) 
dvMaxZ Maximum z value (see the next paragraph) 


You might get a little hung up on D3DVALUE and dvMinz and dvMaxz. ІІІ explain, briefly. A D3DVALUE isa 
float, plain and simple. Since D3D isa 3D API, it takes into account а z value along with an x and a y to 
do rendering. Since youre just using x and y, you dont really care about z, so you'll use 0.0 for dvminz and 
1.0 for dvMaxz (these are the normal values for these members) and forget about it. 


О псе you ve got a p3Dv rEWPORT7 filled out, set your devices viewport to it using 
IDirect3DDevice7::SetViewport. 


HRESULT IDirect3DDevice7::SetViewport( 
LPD3DVIEWPORT7 lpViewport 
); 


T his function returns озо ок if successful and an error value if not. T he 1pviewport parameter is just a 
pointer to a o30v1EWPORT7. T he following code is what you might use to set a devices viewport, assuming 
you are at a 640x480 resolution and want to use the entire screen. 


D3DVIEWPORT7 vp;//vp stands for viewport 
vp.dwX=0; 
vp.dwY=0; 
vp.dwWidth=640 ; 
vp.dwHeight=480; 
vp 
vp 
| 


.dvMinZ-0.0; 
.dvMaxZ-1.0; 
pd3ddev-»SetViewport(&vp); 


N ot too rough, right?T his is mostly like telling DirectX twice what you want to use— once when you 
set the mode and once when you set the viewport. M ost of the time, you'll want to use the entire 
surface for the viewport, but there are times when you might not, such as when you have a frame around 
the playing area. 
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RENDERING 


T he stage is set, and your objects are initialized. You're ready to start drawing. Unfortunately, drawing 
objects іп D3D is absolutely nothing like drawing objects in D irectD raw. In D 3D, you generally adhere 
to the following steps: 


1. Clear out the viewport using IDirect3DDevice7::Clear. 

Те! D3D you want to begin drawing by calling IDirect3DDevice7::BeginScene. 
D o your drawing using IDirect3D7Device7::DrawPrimitive. 

Tell D3D you are done drawing by calling IDi rect3DDevice7::EndScene. 

Flip the surfaces (assuming that you are writing to the back buffer). 


сл > оу ко 


All of this is done each time Prog_Loop Is executed. 


IDIRECTSDDEVICET7IECLEAR 


In almost all cases, you will want to clear out the entire rendering surface each frame. Т his differs from 
what you did in DirectD raw, where you used update rectangles and attempted to do as little blitting 
as possible. 


W hy the difference? W dll, assuming you have any hardware acceleration at all on your video card (and 
chances аге you do have alittle), using D irect3D to render is just so much faster than doing the same 
thing with D irectD raw, because of the hardware acceleration. So, to clear out the buffer, you use 
IDirect3DDevice7::Clear. 


HRESULT IDirect3DDevice7::Cleart( 
DWORD dwCount, 
LPD3DRECT lpRects, 
DWORD dwFlag 
DWORD dwColo 
D3DVALUE dvZ, 
DWORD dwStencil 

)3 


5, 
r, 


T here are lots of parameters here, most of which you dont care about. Like all DirectX functions, this 
function returns an HRESULT, which contains 03D_ox if successful or something else if not. Table 24.2 
explains the parameter list. 
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Table 24.2 IDirect3DDevice7::Clear Parameters 


Parameter Purpose 

dwCount The number of nECTS pointed to by 1pRects. Мау be 0 if 1pRects 
is NULL. 

ІрКес%5 А pointer to a list of ВЕСТ$ that will be cleared by this function. 
May be NULL to clear the entire viewport. 

dwFlags Flags specifying how the clear is to be performed (see Table 24.3). 

dwColor A color value to clear the target (discussed in a moment). 

dvZ A z value to assign on the z buffer. (Don't worry about it; you don't 
use z buffers.) 

dwStencil A stencil value to assign the stencil buffer. (You dont use stencil 
buffers.) 


| need to add some explanation to the dur1ags and dwColor parameters. 1711 start with awF1ags. 
Table 24.3 lists and describes the various flags that can be used in this parameter. 


Table 24.3 Flags for Clear 
Flag Meaning 


D3DCLEAR TARGET Clear out the target surface, so dwColor is valid. 


D3DCLEAR_STENCIL Clear out the stencil buffer, so dwStencil is valid. (You aren't 
using stencil buffers, so you don't care.) 


D3DCLEAR ZBUFFER Clear out the z buffer, so dvz is valid. (You arent using z buffers, 
So you dont care.) 


So, dwFlags tells you which of the awcolor, dwStencil, and dvz parameters are valid. For your purposes, 
you will only be using D3DCLEAR. TARGET. 


T hat brings us to dwCo1or. If you recall from the discussion of D irectD raw, you had to deal with calcula- 
tions involving members of the poP1xELFORMAT structure In D 3D, that need is gone T here is a simple 
macro you use to determine the color— D 3D RGB. It takes three parameters— a red value, a green value, 
and a blue value, each in the range from 0.0 to 1.0. Treat 0.0 the same as 0, and 1.0 the same as 255 in the 
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GDI ков macro. So, if you wanted to clear the viewport to white, you would do the following. 


//clear viewport to white 
lpd3ddev->Clear(0,NULL,D3DCLEAR_TARGET,D3DRGB(1.0,1.0,1.0),0,0); 


N ormally, of course, you'll use D 3D RGB (0.0,0.0,0.0) to clear out the target surface so that you have 
anice, fresh black surface to work with. But clearing out the viewport is not the only use of 
IDirect3DDevice7::Clear. You can also use this function to perform color fills, just as you did with 
B1t. T he mechanism changes just a little bit. Like the D irectD raw method, you still fill out a ВЕСТ with 
information about the area you want to fill, and you pick acolor using the D 3D RGB macro and then 
call Clear. 


//rcFill contains information about the area to fill 
//dwColor contains a color constructed with the D3DRGB macro 
lpd3ddev-»5Clear(1,&rcFill,D3DCLEAR TARGET,dwColor,0,0); 


Additionally, if you have several rectangles you need filled with the same color, you can make an array, pass 
the number of кестѕ in the first parm and a pointer to the first вест in the second parm, and do it. 


1lDiRECTZXDDEvicgeE7issEiEGINECENE AND 
1lDiRECTZXDDEvicgE7s$s8ENDASCENE 


Because of the intimate relationship between these two functions, | thought it best to discuss them at the 
same time. You are about to make a rendering sandwich, and these functions are the slices of bread. 


HRESULT IDirect3DDevice7::BeginScene(); 
HRESULT IDirect3DDevice7::EndScene(); 


N either takes a parameter, and both return the usual HRESULT value, with success indicated by озо ок. 
BeginScene tels D3D that you are ready to draw. EndScene tells D 3D that you are done drawing. 


1lDiRECTZXDDEvicge7ssDrTmuTmXximiTive 


N ow, and finally, comes the actual rendering of primitives. A primitiveis just a generic term for a geometric 
object. T here are several types, including points, lines, and triangles. You are concerned mainly with trian- 
gles, but once you can draw one of them, you can draw the others without difficulty. 


T he DrawPrimitive function of 1Direct3DDevice is probably the most complex DirectX function 
| will cover in this book. 


HRESULT IDirect3DDevice7::DrawPrimitive( 
D3DPRIMITIVETYPE dptPrimitiveType, 
DWORD  dwVertexTypeDesc, 

LPVOID lpvVertices, 
DWORD  dwVertexCount, 
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DWORD  dwFlags 
DN. 


DrawPrimitive takes a number of parameters (explained in Table 24.4 and in the following text) and 
returns the standard HRESULT, with 030 ok indicating success. 


Table 24.4 DrawPrimitive Parameters 


Parameter Purpose 

dptPrimitiveType The type of primitive to be drawn (discussed in the next section). 
dwVertexTypeDesc The format of the vertices to be drawn (discussed in a moment). 
lpvVertices A pointer to a list of vertices (discussed in a moment). 
dwVertexCount The number of vertices pointed to by 1pvVertices. 

dwFlags Either 0 or D3DDP_WATT.You'll be using 0. 


| look at that table and think back to when | first looked at D irect3D and felt my stomach drop because it 
seemed so complicated. It's really not so bad, as long as it's explained correctly. 


DPTPRIMITIVE TYPE 

dptPrimitiveType IS Of type D3DPRIMITIVETYPE, an enumeration. Table 24.5 lists the possible values 
and their meanings. Some of them are a little vague and need extra explanation, but well have picture 
time in a moment. 
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Table 24.5 D3DPRIMITIVETYPE Values 


Value Meaning 

D3DPT_POINTLIST Used to draw a series of points.This is useful for making 
a star field. 

D3DPT_LINELIST Used to draw a series of lines. 

D3DPT_LINESTRIP Used to draw aseries of lines connected end to end. 

D3DPT_TRIANGLELIST Used to draw а series of triangles. 

D3DPT_TRIANGLESTRIP Used to draw a series of triangles that are linked (more 
on this later). 

D3DPT_TRIANGLEFAN Used to draw a series of triangles in a fan shape (more on 
this later). 


T he first four should be pretty self-explanatory. D3DPT_TRIANGLESTRIP and D3DPT TRIANGLEFAN area 
little fuzzier, so 171 show you pictures to give you a better idea of what | mean. 


Figure 24.2 shows a triangle strip using six vertices. V 0 through V 5 аге the end points, or vertices, and 

they define triangles 1 through 4. Triangle 1 is defined by V 0, V 1, V 2; Triangle 2 is defined by V 1, V 2, 
V 3; Тпапае 3 is defined byV 2, V 3, V 4; and Triangle 4 is defined by V 3, V 4, V 5. In all cases, triangles 
next to one another on the strip share one side. 


Figure 24.2 
A triangle strip 


Triangle 2 
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Figure 24.3 shows a triangle fan. T he difference between a fan and a strip is obvious once you see what 
they look like. A triangle fan uses the first vertex (V 0) in all the triangles and uses the other two vertices to 
complete the triangle. Again, adjacent triangles end up sharing a side, and additionally, all triangles share a 
single vertex. 


Figure 24.3 


A triangle fan 


Triangle 4 


DWVERTEXTYPEDESC AND LPVVERTICES 


T hese two parameters are joined intimately, so by discussing one, you must discuss the other. T here is 
actually a great deal of information regarding these two parameters, but because you are just using D 3D 
as a 2D rasterizer, you will only be touching the tip of the iceberg. 


T he dwVertexTypeDesc parameter contains a combination of flags describing what kind of vertices you 
are using. T here are many ways you can represent a vertex, and to accommodate that, M icrosoft came up 
with the FlexibleVertex Format (FV F) to allow you to express the many types of vertices you might be 
inclined to use Table 24.6 lists and describes the various FV F flags. 
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Table 24.6 Flexible Vertex Format Flags 


Flag Meaning 

D3DFVF_DIFFUSE The vertex contains a diffuse color (we'll get to diffuse colors а 
bit later). 

D3DFVF. NORMAL The vertex contains a surface normal (this is vector stuff, and 
you won't be using vectors). 

D3DFVF_SPECULAR The vertex contains a specular color (you won't be using 
specular highlights, either). 

D3DFVF_XYZ The vertex contains untransformed position data. 

D3DFVF_XYZRHW The vertex contains transformed position data. 

D3DFVF_XYZBN This is for vertex blending, which you won't be doing. п is а 


value 1 through 5. 


D3DFVF_TEXn This specifies how many sets of texture coordinates the vertex 
has. n is a value 0 through 8. 


D3DFVF TEXTUREFORMATn This specifies in what format the texture coordinates 
are.nis a value 1 through 4. 


Sound complicated? It is. Luckily, M icrosoft knew that people like us would exist, and they did a nice 
thing for us by making a vertex type that we can use for our purposes and by making a 030ғуғ * constant 
to use it with DrawPrimitive. Ве sure to send M icrosoft a thank you note. 


T he vertex type is called p3pTLVERTEX, and the FV F constant associated with it is D3DFVF. TLVERTEX. 
Actually, this type has more information than you really need, but you can just ignore what you dont use. 
T heTL part stands for “transformed and lit” You wont be making use of 0 30 transformation and light- 
ing. You'll specify all the information pertinent to the primitive yourself. 


typedef struct  D3DTLVERTEX { 
D3DVALUE sx; 

D3DVALUE sy; 

D3DVALUE sz; 

D3DVALUE rhw; 

D3DCOLOR color; 

D3DCOLOR specular; 
D3DVALUE tu; 

D3DVALUE tv; 

} D3DTLVERTEX, *LPD3DTLVERTEX; 
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T his isnt the actual declaration for D3DTLVERTEX, so dont be surprised if you see something bizarre when 
looking it up in the help files. T here are anonymous unions for each of the members. Table 24.7 lists the 
members and their meanings. 


Table 24.7 D3DTLVERTEX Members 


Member Purpose 

5х x-coordinate of the vertex 

sy y-coordinate of the vertex 

52 z-coordinate of the vertex 

rhw Reciprocal of the homogenous w-coordinate 
color Diffuse color 

specular Specular color 

tu First texture u-coordinate 

tv First texture v-coordinate 


T he sx, sy, and sz members are intuitive enough. T hey are the coordinates at which the vertex exists. 

T he rhw explanation has to do with matrix multiplication and homogenous coordinates, and you really 
dont want to hear about it, so just trust me and put a 1.0 in your rhw. Color and specular are your two 
colors, diffuse and specular. You dont need to worry about specular— it's just added baggage. tu and 
tv are texture coordinates. 111 get to texture a little later, because it is a discussion in its own right. 


The ipVertices parameter of DrawPrimitive is just a pointer to an array of whatever type of vertex 
you specify using dwVertexTypeDesc, Which in this case will always be D3DTLVERTEX. 


A SIMPLE DiReEcCTSD EXAMPLE 


T his section is subtitled "T he Spinning Technicolor N acho of D eath.” Just like you did when you got into 
GDI by plotting single pixels, you will similarly immerse yourself in Direct3D by drawing its most com- 
mon primitive— the triangle. 
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CAUTION 


In order to compile a Direct3D program, your application needs to include d3d.h, not 
d3d8.h, because you are using version 7 of the API, not version 8. However, the library file 
required is still d3d8.lib, no matter what version you use. 


Traditionally, the “hello world” program for a 3D API is a triangle spinning in three dimensions. Because 
you are not using the third dimension, you will instead have a slight variation on this simple example. T he 
triangle will rotate in two dimensions instead of three. 


Load up 150Н ех24 1.срр and run it, because Figure 24.4 doesnt do it justice You really need to see it in 
color. It shows a shaded triangle with one red corner, one blue corner, and one green corner, slowly rotat- 
ing around the center of the screen. 


Figure 24.4 


Spinning Technicolor 
Nacho of Death 


T his program is about as simple as you can get with D irect3D. It is even simpler than any example using 
actual 3D math with matrices, because you dont have to set up any transformations. Take a look at how 
this example was built so that you can move on to bigger and better things. 


GLOSALS 


IsoH ех24 115 based on IsoH ex1 1, with D irectD raw stuff added. Globals include the normal 1 РПІ- 
RECTDRAW7, LPDIRECTDRAWSURFACE7 for the primary surface and the back buffer, and also a few globals 
you have not yet seen— mainly the stuff to set up Direct3D. 


INTRODUCTION TO DikRECTZXD 551} 


//IDirect3D7 

LPDIRECT3D7 lpd3d-NULL; 
//IDirect3DDevice 

LPDIRECT3DDEVICE7 lpd3ddev-NULL; 
//vertices 

D3DTLVERTEX vert[3];//three vertices 
//angle, used for vertex calculations 
double angle=0.0; 


1pd3d is a pointer to your 1Direct307 object, which you have to Query Interface from out 1pdd. 
1pd3ddev is your 3D device, which you create from 1р434. vert is an array of D3DTLVERTEX, and you 
use it for drawing. angle is used to calculate the positions of the vertices stored іп the vert array. 


INITIALIZATION AND CLEANUP 


M ost of this will be familiar, except that the surface creation is no longer from 

DD Funcs.h/ DDFuncs.cpp, because you need to add a capability to the surface. T he rest involves setting 
up Direct3D and initializing the parts of your vertex array (vert) that will not change throughout the 
course of the application. And so, for your perusal, here is the Prog_Init function: 


bool Prog_Init() 
{ 


lpdd-LPDD, Create(hWndMain,DDSCL EXCLUSIVE | 
DDSCL FULLSCREEN | DDSCL ALLOWREBOOT); 
//set the display mode 
lpdd-»SetDisplayMode( SCREENWIDTH,SCREENHEIGHT,SCREENBPP,0,0) ; 


T his bit has not changed since you first started using D D Funcs.h/ D D F uncs.cpp. Y ou create your 
IDirectDraw7 Object, and you still set the display mode. Т heres nothing new here. 


//create primary surface 

DDSURFACEDESC2 ddsd; 
memset(&ddsd,0,sizeof(DDSURFACEDESC2)) ; 
ddsd.dwSize=sizeof (DDSURFACEDESC2) ; 
ddsd.dwFlags=DDSD_CAPS | DDSD_BACKBUFFERCOUNT; 
ddsd.dwBackBufferCount-l; 
ddsd.ddsCaps.dwCaps-DDSCAPS PRIMARYSURFACE | 

DDSCAPS FLIP | DDSCAPS COMPLEX | DDSCAPS_3DDEVICE; 
lpdd-»CreateSurface(&ddsd,&lpddsPrime,NULL) ; 


B52) 1S0METRIC GAME PROGRAMMING WITH, DIRECTX 7,0 


Earlier in this chapter, | told you about poscaps_3DDeEvIceE, which allows you to use a surface as a render- 
ing target for aD3D device. H ence, the way you create your primary surface has changed subtly, which 
means that you can no longer use D D Funcs.h/ D D Funcs.cpp to create your primary surface. (D ont worry. 
You'll make а D 3D Funcs.h/ D 3D Funcs.cpp in the next chapter.) 


You probably will never set your primary surface as the rendering target, but for debugging purposes, 
you might want to use it in a limited way, so that it doesnt really hurt anything. 


//create back buffer 

DDSCAPS2 ddscaps; 

memset (&ddscaps,0,sizeof(DDSCAPS2)); 
ddscaps.dwCaps=DDSCAPS_BACKBUFFER | DDSCAPS_3DDEVICE; 
lpddsPrime-»GetAttachedSurface(&ddscaps,&lpddsBack); 


Just as the primary surface is now a D 3D rendering target, so must the back buffer be. Setting this up is 
less involved than creating the primary surface, but it is necessary, because the back buffer is the surface 
to which you want D 3D to render. 


//get the idirect3d pointer 
lpdd-»QueryInterface(IID IDirect3D7,(void**)81pd3d) ;//ICKY COM STUFF! 


N ext on the list is to get your 1Direct307 pointer by using the evil COM QueryInterface method 
of your IDirectDraw7 object. N ow you're ready to make your 3D device. 


//create the idirect3ddevice (hack method) 
if (FAILED(1pd3d- 
>CreateDevice(IID_IDirect3DTnLHalDevice, lpddsBack,&lpd3ddev)))//try tnl 
if (FAITLED( 1 pd3d->CreateDevice(IID_IDirect3DHALDevice, 
lpddsBack,&lpd3ddev)))//no tnl; try hal 
if(FAILEDCIpd3d-»CreateDevice(IID IDirect3DMMXDevice, 
lpddsBack,&lpd3ddev)))//no hal; try mmp 
if(FAILED(CIpd3d-»CreateDevice(IID IDirect3DRGBDevice, 
pddsBack,&lpd3ddev)))//no mmx; resort to 


2—1 


rgb 
return(false);//problem; return false 


T his is the hack method. You use it to create your 3D device, using the back buffer as the rendering target. 
| took out all the brackets in order to take up less space, but this remains the exact same method | showed 
you earlier. Try the most advanced device first, and gradually settle for less and less capability. 


//set up viewport 
D3DVIEWPORT7 vp; 
vp.dwX-0; 
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.dwY-0; 
.duWidth-SCREENWIDTH; 
.duHeight-SCREENHEIGHT; 
.dvMinz-0.0; 
p.dvMaxZ=1.0; 

/set viewport for device 
pd3ddev->SetViewport(&vp); 


N ow that you havea 3D device, you must set up the viewport for it. You'll be using the entire screen, so 
dwX, dwY, dwWidth, and dwHeight are set appropriately. Set the z values to their “usual” values, even 
though you dont care at all about z. 


//initialize the vertices (partially, anyway) 
vert 


[0] 
vert[ 
vert[ 
vert[ 
vert[ 
vert[ 
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.color=D3DRGB(0.0,1.0,0.0);//set the color for this vertex 
.specular-0;//zero for specular 

].rhw-1.0;//rhw is 1.0 

].tu-0.0;//0.0 for both texture coordinates 

1.%у-0.0; 

].sz-0.5;//static 2 value 


Finally, set up the static parts of your vertex array. D uring this example, the only values that will change 
are sx and sy, so you can safely fill in the rest of the values. For vertex 0, you have a diffuse color of pure 
green, no specular color, and an rhw of 1.0 (you need this to make it look right). You need a texture coor- 
dinate of (0.0,0.0) since you arent using textures yet, and to top it off, you need an sz value of 0.5.T he 
sz Value doesnt really matter. 


vert[1 
vert[1] 
vert[1] 
vert[1] 
vert[1 
vert[1] 
[2] 
2 
2 
2 
2 
[2 
n 


ver 


vert[2] 
vert[2]. 
.tu=0.0;//0.0 for both texture coordinates 
vert[2].tv-0.0; 
vert[ 


vert[2] 


ret 


ct 


u 


].color-D3DRGB(0.0,0.0,1.0);//set the color for this vertex 
.specular-0;//zero for specular 

.rhw-1.0;//rhw is 1.0 

.tu=0.0;//0.0 for both texture coordinates 

1.%у-0.0; 
.Sz-0.5;//static z value 

.color=D3DRGB(1.0,0.0,0.0);//set the color for this vertex 
.specular-0;//zero for specular 


rhw-1.0;//rhw is 1.0 


].sz90.5;//static z value 
rn(true);//return success 
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T hen set up the other two vertices, mostly with the same values, except for color. Vertex 1 is bright blue, 
and vertex 2 is bright red. 


On the other end of the program, Prog. Done, simply do a safe release of all your DirectX objects, which 
you should be accustomed to by now. 


MAIN LOOF 


T he really sick part of this example is that the initialization takes longer than the main loop. I'm not kid- 
ding. Take a look: 


~ 


void Prog_Loop() 

{ 
//set up the vertex positions 
vertL0O].sx=cos(angle)*240.0+320.0; 
vertL0O].sy=sin(angle)*240.0+240.0; 
vertL1].sx=cos(anglet+2*PI/3)*240.0+320.0; 
vertl1l].sy=sin(anglet+2*P1/3)*240.0+240.0; 
vert[2].sx-cos(angle-2*PI/3)*240.0-320.0; 
vert[2].sy-sin(angle-2*PI/3)*240.0—-240.0; 
//add to the angle for next time 
апд1е+=РІ/180; 


Т hese six lines calculate the sx and sy values for each of the vertices based оп the value of the global vari- 
able angle. If you arent familiar with trigonometry, dont worry about it, because this is the only time | use 
it in this book, and only to make the nacho spin. 


After the vertex positions are calculated, the angle is increased by pi/ 180, which is the same as turning the 
triangle 1 degree. 


//clear the viewport to black 
lpd3ddev->Clear(0,NULL,D3DCLEAR_TARGET,0,0,0); 
//start the scene 

Тразааеу - > ВедіпЅсепе( ); 


№ ext, clear out the entire viewport and tell D3D you are ready to begin the scene. 


//draw the triangle 
lpd3ddev-»DrawPrimitive(D3DPT TRIANGLELIST, 
D3DFVF. TLVERTEX,vert,3,0); 


After all that setup and all those calculations, the entire functionality of this program boils down to this 
single line a DrawPrimitive Call. Т his is what draws the triangle on the screen. All the rest just sets every- 
thing up so that you can do so. 
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//end the scene 
lpd3ddev->EndScene(); 

//flip 
lpddsPrime->Flip(NULL,DDFLIP_WAIT); 


} 


Finally, end the scene, and flip so that the back buffer is now visible. T hen return so that you can process 
input and draw another frame. 


You're probably disappointed, | know. Direct3D should be so much more complicated than what I've just 
shown you. Actually, it is more complicated. Y ou're just using a limited subset with no 3D math involved. 
H owever, even if you included everything else in D irect3D, youre still just drawing triangles. 


T his wraps up the Direct3D basics. If you can draw one triangle, you can draw a billion of them. | have 
a bit more to cover in D irect3D, because colored triangles wont get you where you need to go. W hat you 
need is a way to do textures, and then youre good to go for ISO 3D. 


TEXTURES 


N ifty colored triangles are neat, and they are the basis of all other 3D graphics, but you want more, right? 
You want the ability to place images on the screen much as you did in DirectD raw, while making use of 
the hardware acceleration you can get from Direct3D. 


Of course, you can still use D irectD raw's 81t to copy rectangles from surface to surface, much as you 
have been doing all along. After all, these are still just surfaces, at least in D irectX 7.0 (this isnt so in 
D irectX 8.0, which has no в1+ to speak of). 


T he other road you can take is to use textures. After all, the rectangles you ve been blitting throughout this 
book are nothing more than two triangles with a common line between them. 


WHAT 15 я TEXTURE? 


In DirectX 7.0, a texture is just a special kind of surface It has the capabilities of DDSCAPS_TEXTURE to 
indicate that it is a texture surface, and the width and height each have to be a power of 2, although they 
need not be the same power of 2.W ith that in mind, 64x64, 128x64, 64x128, and 128x128 are all 
valid measurements for a texture, whereas something like 65x21 is not. 


Depending on hardware, support for nonsquare textures (like 12864) can be limited to allow only a sin- 
gle power difference (so, 128x64 is allowed, but 128x332 is not). Also, a textures maximum size is limited 
by hardware, but just about all hardware supports sizes up to 256х256, which is more than sufficient for 
your needs. 


For maximum compatibility, you need to follow a few rules. First, always use a square texture. Second, 
dont use a texture greater than 256x250. T hird, use only a single texture at a time. 
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T he "single texture at a time" rule exists because some cards support multitexturing— that is, combining 
up to eight textures on a single polygon (triangle). M any cards still do not support this, so you'll use just a 
single texture at any given time. You dont really need multitexturing anyway. 


T his is how you create a texture: 


//\pdd is a pointer to an IDirectDraw/ object 

//\pddsTex is a LPDIRECTDRAWSURFACE7 variable 

//TEXTUREWIDTH and TEXTUREHEIGHT specify the size of the texture 
DDSURFACEDESC2 ddsd; 

memset (&ddsd,0,sizeof(DDSURFACEDESC2) ) ; 
ddsd.dwSize=sizeof(DDSURFACEDESC2) ; 

ddsd.dwFlags=DDSD_WIDTH | DDSD_HEIGHT | DDSD_CAPS; 
ddsd.dwWidth=TEXTUREWIDTH; 

ddsd.dwHeight=TEXTUREHEIGHT ; 
ddsd.ddsCaps.dwCaps=DDSCAPS_TEXTURE; 
lpdd->CreateSurface(&ddsd,&lpddsTex,NULL);//create the surface 


It’s just like creating an off-screen surface, with the exception of the size requirements and the 
DDSCAPS TEXTURE instead Of DDSCAPS OFFSCREENPLAIN. 


TEXTURE MAPPING AND TEXTURE 
COORDINATES 


After you've created a texture, your next task is using it. In order to use it, you must first know something 
about how texture mapping works, at least on a conceptual level, and you must be able to specify texture 
coordinates. 


If you think back to Chapter 20, “Isometric Art,” when you did tile slanting, it was very much like texture 
mapping. You took a square texture and stretched and slanted it into a rhombus shape. T his is not true tex- 
ture mapping, but it has similarities. 


You dont have to go into the intricacies of how texture mapping works on а pixel-by-pixe level. T hat part 
has been done for you by the people who programmed D irect3D. Y ou just have to know what information 
to send Direct3D so that it all comes out looking right. Figure 24.5 shows a texture and a texture mapped 
polygon. T he texture (on the left) shows its four corners with the coordinates that correspond to them. 
Likewise, the polygon (on the right) has its four corners (vertices) marked with their coordinates (no actu- 
al numbers, of course). Table 24.8 shows how the textures coordinates correspond to the vertices. 
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Figure 24.5 


Texture Texture Mapped Polygon A texture and a texture- 
(WIDTH,0) mapped polygon 


(х1,ү1) 


Table 24.8 Texture Coordinates to Vertices 


Texture Coordinate Vertex Coordinate 
(0,0) О У) 
(WIDTH,0) CUIR 
(0, HEIGHT) (X2 12) 
(WIDTH,HEIGHT) (X953) 


Based on these coordinate matchups, you can do a whole lot of linear algebra and figure out that a particu- 
lar pixel in a particular polygon matches up with such-and-such a pixel within the texture Or, you can just 
геу оп Direct3D to do it for you. T hat is Direct3D 5 entire purpose— to make fancy triangles. 


H owever, you have to take it just one small step further, since texture coordinates are not specified between 
0 and итотн and 0 and HEIGHT, but rather in the range of 0.0 to 1.0, where 0.0 corresponds to the 0 
coordinate on the texture surface (duh!) and 1.0 corresponds to WIDTH (Or HEIGHT, depending on the tex- 
ture coordinate). 


T he horizontal coordinate is called U by D irect3D, and the vertical coordinate is called V. T he reasons for 
these letters? X , Y, and Z were already taken, and W is for homogenous coordinates, so they decided to 
work their way backward through the alphabet. In other words, | dont really know, but that's my guess. 
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Т he various U and V coordinates аге stored in the tu and tv members of D3DTLVERTEX. Pretty simple, 
eh? After setting up the appropriate texture coordinates for each vertex (there will be a lot more about this 
in Chapter 25, “T he M uch Anticipated 150 3D”), you have only one thing left to do in order to make use 
of your texture. 


//set tells Direct3D what texture we wish to use 
1lpd3ddev-»SetTexture(O,lpddsTex); 


T he first parameter of 1Direct3DDevice::SetTexture 15 a number that specifies the texture stage. 

T here are eight stages, numbered 0 through 7. You arent multitexturing, so you only care about the first 
texture stage (0). After а call to Set Texture, rendering a texture mapped triangle is as simple as a call 
to DrawPrimitive. 


TEXTURE MAPPING EXAMPLE 


T his example is called "T he Spinning Texture-M apped Saltine of D eath” (see Figure 24.6), and other 
than a few lines, it is identical to |soH ех24 1.cpp. Following are the changes: 


= T here are four vertices instead of just three (hence a Saltine and not a nacho). 

" T hetexture surface is created and is loaded with a texture. 

= T he vertices now have texture coordinates. 

= Because you are rendering a square and not a triangle, the call to DrawPrimitive uses a triangle strip, not 
a triangle list. 

= | changed the colors of the vertices to give the illusion that one corner is lit and the opposite corner is 
in shadow. 


T he changes аге so minor I'm not even going to show the code, because | ve already shown the snippets 
that do it. It would be like listing IsoH ех24 1.срр twice Just be sure to take a look at the code before 
moving on to the next chapter, where you will use texture mapping (a lot). 
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Figure 24.6 
IsoHex24 2.cpp output 


SUMMARY 


One thing this chapter should demonstrate is that Direct3D is not nearly as hard as everyone makes it out. 
| admit, you haven't used a lot of its functionality, such as vectors, matrices, depth buffers, and lighting. 
You dont need all of those things where youre going. Already, you can render a textured square onto the 
screen (and rotate it to boot! Try doing that in DirectD raw), and that is the fundamental way in which you 
will be using Direct3D asa 2D renderer. 


Indeed, once you strip down D 3D to its bare functionality, it's not so intimidating at all. At the same time, 
it does a lot for you. T he texture mapping is superb, and you have only two polygons per object, unlike а 
“real” 3D game, in which an object can consist of thousands of polygons. 

N ext up, well take the knowledge in this chapter and adapt it to the unique needs of an isometric game. 
МІ show you a few tricks, too, that'll make life a lot easier (for one thing, меге going to get rid of the 

M ouseM ap).T he really good stuff, the stuff you've been waiting for, is next. 
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" Тік SELECTION/MoOuUSEMAPPING 
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his is what you have been waiting for. О ver hill and dale youve trudged through 2D isometric 
algorithms with the promise that using 3D was just around the corner. You have finally 
rounded that corner. 


Using an API like D irect3D to do an isometric display is called "ISO 3D” even though all of the drawing 
is still 2D -based. Such is life. 


T he first thing you'll do here is put together a group of functions іп a header and cpp file much like you 
did in D irectD raw with D DFuncs. T hen we will discuss what changes occur when you move from a 2D 
АР! to a3D API. All in all, it should be great fun. 


DAXDFruwcsiH/DzxpDftruwcsacegg 


М uch as you have relied on D D Funcs.h/ D D Funcs.cpp throughout most of the book, so shall you come 
to rey on D3D Funcsh/ D 3D F uncs.cpp to help you create and manage the D 3D pointers you will be 
using in this chapter. Table 25.1 lists the functions in the D 3D Funcs minilibrary. 
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Table 25.1 Functions from D3DFuncs.h/cpp 


Function Purpose 

LPD3D_Create Creates ап IDirect3D7 object using an LPDIRECT- 
DRAW7 pointer. 

LPD3D_Release Cleans up an IDirect3D7 object. 

LPD3DDEV. Create Creates an IDirect3DDevice7 object using an 
LPDIRECT3D7 pointer. 

LPD3DDEV SetViewport Sets a viewport for an IDirect3DDevice7. 

LPD3DDEV Clear Clears a viewport. 

LPD3DDEV DrawTriangleList Draws a triangle list using a D3DTLVERTEX 
array/pointer. 

LPD3DDEV DrawTriangleStrip Draws a triangle strip using a D3DTLVERTEX 
array/pointer. 

LPD3DDEV Release Cleans up an IDirect3DDevice7. 

LPDDS CreatePrimary3D Creates a primary surface that can be used as a 


3D device's rendering target. 


LPDDS_GetSecondary3D Gets a back buffer that can be used as a 3D 
device's rendering target. 


LPDDS CreateTexture Creates a texture surface. 


LPDDS CreateTexturePixelFormat Creates a texture surface and specifies what 
pixel format it will have (more on this a bit later). 


VERTEX Set Sets up the values in a D3DTLVERTEX. 


T his is a pretty sparse little library of functions, really, but if you look back, so was 
DDFuncsh/ DD Funcs.cpp, and you've done plenty of stuff using that simple little set of functions. And 
so shall it be with D 3D Funcsh/ D 3D Funcs.cpp. 
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РОО FUNCTIONS 


T here are two of these. О ne creates the 1Direct3D7 object (LPD3D_Create), and the other cleans it up 
afterwards (LPD3D_Release). 


//create the IDirect3D7 interface 
LPDIRECT3D7 LPD3D Create(LPDIRECTDRAW7 1раа); 


LPD3D. Create takes a single parameter (1pda). It uses QueryInterface to call the proper interface to 
use for D 3D stuff and then returns the newly gotten | PbrRECT307 pointer. Typically, this function is 
called during Prog Init. 


//clean up an IDirect3D7 
void LPD3D Release(LPDIRECT3D7* 1раза); 


During Prog. Done, you need to clean up all the DirectX stuff you've used. To clean up the LPDIRECT3D7 
pointer, you need only call LPD3D_Release and send a pointer to the LPprRECT307 variable. 


LT"DzDDEV FUNCTIONS 


In spite of the many tasks that an IDirect3DDevice7 object can be called on to do (and believe me in a 
"normal" typeof 3D program, there are plenty of diverse tasks), we are concerned with only six functions. 


//create the device 
LPDIRECT3DDEVICE7 LPD3DDEV Create(LPDIRECT3D7 lpd3d,LPDIRECTDRAWSURFACE7 lpdds); 


№ aturally, after you've called LPD30 Create, your next task (after creating the appropriate surfaces) is to 
create the 3D device itself. То do this, you call LPD3DDEV_Create and pass ап LPDIRECT3D7 pointer (used 
to create the device) and ап LPDIRECTDRAWSURFACE7 pointer (used as the rendering target). T he return 
value is a pointer to the new device, which you can begin to use immediately. T his function uses the 
"hack" method of creating a 3D device. 


//set up the viewport 
void LPD3DDEV SetViewport(LPDIRECT3DDEVICE7 lIpd3ddev,DWORD x,DWORD y,DWORD 
width,DWORD height); 


After your device is created, you need to set up the viewport parameters. Because you ignore the z- 
coordinate, you need only specify the upper-left corner (x and y) and the width and height of the view- 
port. T his function returns no value but does fill in a p30viEwPoRT7 structure and sets the device to use 
that viewport. 


//clear out the viewport 
void LPD3DDEV Clear(CLPDIRECT3DDEVICE7 lpd3ddev,D3DCOLOR color); 
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| didnt bother making functions for BeginScene ОГ EndScene, because these functions would take up 
more typing time than just calling them in the first place. Н owever, since you are using only one part of 
the IDirect3DDevice7::Clear member function, and you're only interested in clearing out the entire 
viewport, making a special function for it seemed appropriate. Calling LPb3DDEV. C1ear with the pointer 
to the device and a color causes the entire viewport to be filled with that color. 


//draw triangle list 

void LPD3DDEV DrawTriangleList(LPDIRECT3DDEVICE7 lpd3ddev,D3DTLVERTEX* pver- 
tices,DWORD dwvertexcount); 

//draw triangle strip 

void LPD3DDEV DrawTriangleStrip(LPDIRECT3DDEVICE7 lpd3ddev,D3DTLVERTEX* pver- 
tices,DWORD dwvertexcount); 


T hese functions are so similar that | thought it best to discuss them together. T he first draws a triangle 
list, and the second draws a triangle strip. T hey take as parameters a pointer to the device and a pointer to 
an array of D3DTLVERTEXS, along with a count of how many vertices are in the array. It's pretty simple, 
really, and it beats the heck out of typing D3DFVF_TLVERTEX every time you want to call DrawPrimitive. 


//clean up a device 
void LPD3DDEV Release(LPDIRECT3DDEVICE7* lpd3ddev); 


T his is the ubiquitous "cleanup" function, much the same as all the other functions used to clean up 
the various components of DirectX . W hen you're done with a device, usually at the end of a program, 
call this function. 


LT"DD* FUNCTIONS 


Since there is a change in the way you have to set up surfaces to be rendering targets, | needed to add а 
couple of functions to create primary surfaces and back buffers. T hese two functions, described next, work 
about the same as their D D Funcs.h/ D D Funcs.cpp versions, just with a "3D " appended to the end. 


//primary surface as a 3D rendering target 

LPDIRECTDRAWSURFACE7 LPDDS_CreatePrimary3D(LPDIRECTDRAW7 lpdd,DWORD 
dwBackBufferCount); 

//back buffer as a 3D rendering target 

LPDIRECTDRAWSURFACE7 LPDDS GetSecondary3D(LPDIRECTDRAWSURFACE7 1раа5); 


N ow, instead of LPDDS CreatePrimary, YOU use LPDDS. CreatePrimary3D, and instead of 
LPDDS GetSecondary, YOU USe LPDDS_GetSecondary3D. YOu still use LPDDS Release to clean up at the 
end of the program, however. 
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TEXTURE FUNCTIONS 


[уе spoken only briefly about textures and texture surfaces. ІІІ talk about them а great deal more as this 
chapter progresses (since just about everything in ISO 3D relies on the use of textures). 


//create a texture 

LPDIRECTDRAWSURFACE7 LPDDS_CreateTexture(LPDIRECTDRAW7 lpdd,DWORD dwWidth, DWORD 
dwHeight); 
//create a texture with a particular pixel format 

LPDIRECTDRAWSURFACE7 LPDDS CreateTexturePixelFormat(LPDIRECTDRAW/ lpdd,DWORD 
dwWidth,DWORD dwHeight,LPDDPIXELFORMAT lpddpf); 


T hese two functions are quite similar. T he first, LPDDS_CreateTexture, creates a texture surface with the 
given width and height (remember, these must be powers of 2!) with the same pixel format as the primary 
surface. T he second function allows you to supply a pixel format different from that of the primary sur- 
face T he reasons for having this function may not be clear now, but they will be soon; | didn't want to add 
to D Зр Funcs.h/ D 3D Funcs.cpp in the middle of the chapter. 


VECTOR FUNCTION 
T his is just a single function, but it is pretty important and will save you a great deal of work. 


//set vertex data 
void VERTEX_Set(D3DTLVERTEX* pVert,D3DVALUE x,D3DVALUE y, D3DCOLOR color, D3DVAL- 
UE tu, D3DVALUE tv); 


VERTEX. Set allows you to fill out a o30TLvERTEX structure without having to type the variable name a 
billion times. Instead, you can do this concisely in a single line. 


THE DSD SHELL APPLICATION 


If you load 150Н ех25 1.срр you'll see all the basic functionality necessary for aD 3D application. | admit, 
the program doesnt really do anything, but it definitely sets you up nicely so that you can start doing things. 


T he applications in this chapter rely on IsoH ех25 1.cpp as the code base 


PLOTTING TILES 1N 120580 


№ aturally, the first thing you'll want to be able to do is plot tiles, just as you did in 2D. To do so, you need 
an isometric plotting equation (any one will do), some vertices, and some textures. 
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Figure 25.1 shows a standard isometric tile with some coordinates. In 150 3D, you will base everything on 
the middle of the tile, just to make things easy. If youre like me, you like things easy (please try not to 
read anything into that). 


Figure 25.1 


A standard isometric 
tile with coordinates 


(x y+TILEHEIGHT/2) 


So, you have a four-pointed figure, but D 3D draws only triangles. Luckily, this four-pointed figure splits 
nicely into two triangles, as shown in Figure 25.2. T he vertices are numbered V 1 through V 4 and are in 
order of how you must make a triangle strip out of them. Poly1 (really, T RIAN GLE 1) is defined byV 1 
through V 3, and Poly2 is defined by V 2 through V 4. 
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Figure 25.2 


An isometric tile split 
into triangles 


(x y+TILEHEIGHT/2) 


U sing an isometric plotting equation (for example, for staggered maps), filling out an array of vertices 
is quite easy, 


//mapx,mapy are map coordinates 
//TILEWIDTH and TILEHEIGHT are dimensions of a tile 


//vert is an array of D3DTLVERTEX 
//calculate center poin 
D3DVALUE CenterX=(float) 
D3DVALUE CenterY=(float) (mapy*(TILEHEIGHT/2)); 


ГАТ 
VERT 
v2 


Ги "e qpEW т 
< 
[99] 


= c = oc. = М 


EX Se 


TEX Se 


TEX Se 


[EX Se 


t(&vert 


t(&vert[ 


t(&vert[ 


[0] 


t(&vert[0] 


‚Сеп 


],Cen 


‚Сеп 


],Cen 


t (staggered calculation) 
(mapx*TILEWIDTH)+(mapy&1)*(TILEWIDTH/2)); 


terX-TILEWIDTH/2,CenterY,D3DRGB(1.0,1.0,1.0),0.0,0.0); 


terX,CenterY-TILEHEIGHT/2,D3DRGB(1.0,1.0,1.0),0.0,0.0); 


TILEHEIGHT/2,D3DRGB(1.0,1.0,1.0),0.0,0.0); 


terxX,CenterY4 


terX-TILEWIDTH/2,CenterY,D3DRGB(1.0,1.0,1.00,0.0,0.0); 


With this code, you could then progress to a call to LPD3DDEV_DrawTriangleStrip, and you would see 
a white isometric tile (since you have no texture yet). 


But that's not quite good enough. You want a textured isometric tile, which means you need texture 


coordinates and a suitable texture. Figure 25.3 has a possible set of texture coordinates for your tile. 


T his is not the only configuration, of course. Also, it assumes you are using the entire texture, which you 
most likely will. 
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Figure 25.3 


Texture coordinates 
for an isometric tile 


(1.0,0.0) @ Тор 


(0.0,1.0 
(x, y+T ILEHEIGHT/2) 


W ith the addition of texture coordinates, your code for loading a triangle strip becomes as follows: 


//mapx,mapy are map coordinates 

//TILEWIDTH and TILEHEIGHT are dimensions of a tile 
//vert is an array of D3DTLVERTEX 
//calculate center point (staggered calculation) 


D3DVALUE CenterX=(float) ((mapx*TILEWIDTH)+(mapy&1)*(TILEWIDTH/2)); 

D3DVALUE CenterY=(float) (mapy*(TILEHEIGHT/2)); 

/ [N 

VERTEX Set(&vert[0],CenterX- TILEWIDTH/2,CenterY,D3DRGB(1.0,1.0,1.00,0.0,0.0); 
//v2 
VERTEX_Set(&vertL1],CenterXx,CenterY-TILEHEIGHT/2,D3DRGB(1.0,1.0,1.0),1.0,0.0); 
//v3 

VERTEX Set(&vert[0],CenterX,CenterY-TILEHEIGHT/2,D3DRGB(1.0,1.0,1.0),0.0,1.0); 
//\4 

VERTEX Set(&vert[0],CenterX-TILEWIDTH/2,CenterY,D3DRGB(1.0,1.0,1.0),1.0,1.0); 


After this, you would set the texture and draw the triangle strip. T his isnt as hard or as daunting as it 
might have seemed. So, let's do it! 


Go ahead and load IsoH ех25 2.cpp. In this example, | use almost line-for-line the earlier code for setting 
vertices, and | added a line for drawing the triangle strip. T his is what the Prog. Loop function looks like: 
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void Prog_Loop() 
{ 


//clear the viewport to black 
| pd3ddev->Clear(0,NULL,D3DCLEAR_TARGET,0,0,0); 
//start the scene 
lpd3ddev-»BeginScene(); 
//center positions 
D3DVALUE CenterX,CenterY; 
//loop through map 
for(int y=0;y<MAPHEIGHT; у++) 
{ 
for(int x=0;x<MAPWIDTH; х++) 
{ 
//calculate world coordinates for center of tile 
CenterX=(float) (x*TILEWIDTH+(y&1)*(TILEWIDTH/2) ); 
CenterY=(float) (y*(TILEHEIGHT/2)); 
//set up the vertex 
//v 
VERTEX Set(&vert[0],CenterX-TILEWIDTH/2, 
CenterY,D3DRGB(1.0,1.0,1.0),0.0,0.0); 


VERTEX Set(&vert[1],CenterX, 
CenterY-TILEHEIGHT/2,D3DRGB 


I 


т. 
сә 


.0,1.0),1.0,0.0); 


VERTEX Set(&vert[2],CenterX, 
CenterY+TILEHEIGHT/2,D3DRGB 


т. 
c 


40,103,040, 1.05 


ES 

SS. 

< 
Гг» 


VERTEX Set(&vert[3],CenterX-TILEWIDTH/2, 
CenterY,D3DRGB(1.0,1.0,1.0),1.0,1.0); 
/render the triangle strip 
PD3DDEV_DrawTriangleStrip(lpd3ddev,vert,4); 


— 


- 


) 

//end the scene 
lpd3ddev->EndScene(); 

//flip 
lpddsPrime->Flip(NULL,DDFLIP_WAIT); 
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As you can see, this is the same as the preceding code, just nested within two loops. If you take a look at 
texturebmp (the graphic for this example), you will find that it is a 128х128 bitmap, and yet D3D does 
a marvelous job of shrinking and rotating it into your isometric tile shape. 


W ith this example in mind, it is easy enough to extend it to allow for morethan one type of tile You 
would simply make an array of texture surfaces and set the device to use the appropriate one for each tile. 


EL) SPRITES USING DIRECTSD 


Although it would be nice if every graphic in your game were the same size and shape as an isometric tile, 
unfortunately this is just not the case. Your units, objects, trees, mountains, roads, and so on are oddly 
shaped, so you need to do the 3D equivalent of a color key in order for everything to look right. 


Direct3D does have some support for the type of color keys you have used in your 2D programs. 
H owever, using this support is not suggested. | was reading a newsgroup post about it, and the answerer 
(whose name eludes me) said there are other ways to do it. 


At the time, | didnt know what the “other ways" were, but knowing that | would have to use a technique 
for doing this, and also tell others how to do it, and not wanting to do it "the wrong way; | asked around. 


A friend of mine told me what | had to do. It’s alittle bizarre, but not too hard. In order to do it, you 
have to use some of D irect3D 5 alpha functionality. If you havent heard of alpha before, dont worry 
about it too much. It is used to blend colors to make objects look partially transparent (translucent) for 
things like ghosts, pieces of glass, and water. In addition, it can be used to simulate a color key. 


In order to make use of this functionality, you must make a texture that has alpha information. You dont 
need a whole lot of alpha information (just a single bit will suffice), but you do need some. In 16bpp 
mode, with the normal format being 5:6:5 for RGB, giving up a bunch of bits for alpha is the last thing 
you want to do. Luckily, most graphics cards support a 1:5:5:5 ARGB format, so you have to give up 
only 1 bit of green. 


ENUMERATING TEXTURE FORMATS 


So, how do you figure out what texture formats are available to use? Y ou use 
IDirect3DDevice7::EnumTextureFormats and a callback function. 


HRESULT IDirect3DDevice7::EnumTextureFormats( 
LPD3DENUMPIXELFORMATSCALLBACK lpd3dEnumPixelProc, 
LPVOID lpArg 

E 


T his function returns an HRESULT, which is 030 ok if successful and some D3DERR_* value if it fails. T he 
first parameter is the address of your callback function (which | will ge to in a moment), and the second 
parameter (1 pArg) is a pointer used to retrieve information from the callback. 
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TEXTURE FORMAT CALLBACK 


In order to make use of 1Direct3DDevice7::EnumTextureFormats, you must create a callback for it to 
исе. Because you are simply looking for a format with alpha information, retrieving this information is 
quite easy. Н eres an example of what a texture format callback function looks like: 


HRESULT CALLBACK D3DEnumPixelFormatsCallback( 
LPDDPIXELFORMAT IpDDPixFmt, 
LPVOID lpContext 


You can name the function whatever you want, actually. It returns an HRESULT, which is D3DENUMRET_OK if 
you want to continue enumerating, or D3DENUMRET. CANCEL if you want enumeration to end. After you've 
found what you're looking for, you dont need to enumerate any further. T he first parameter is a pointer to 
a DDPIXELFORMAT, which contains the various masks for red, blue, green, and alpha. T he second parameter, 
1pContext, 15 the same pointer you send to EnumTextureFormats in the 1pArg parameter. 


T his is thetexture format callback you'll be using: 


HRESULT CALLBACK TextureFormatCallback(LPDDPIXELFORMAT IpDDPF,LPVOID lpContext) 
{ 

//check the alpha bitmask of the pixel format 

if (1 pDDPF->dwRGBAI phaBitMask) 

{ 


//alpha 
//copy to context 
memcpy(lpContext, 1pDDPF,sizeof(DDPIXELFORMAT )); 
//stop enumeration 
return(D3DENUMRET_CANCEL) ; 
} 
//no alpha found 
//continue enumeration 
return(D3DENUMRET_OK) ; 


In the case of this callback, you arent being picky about the pixel format. It just has to have alpha in it, 
and you'll take the first one. It copies the DDPIXELFORMAT information into the context pointer, so you 
need to send a DDPIXELFORMAT pointer to the enumeration function, like so: 


//enumerate texture formats 

DDPIXELFORMAT ddpf; 

memset (&ddpf,0,sizeof(DDPIXELFORMAT ) ; 
lpd3ddev-»EnumTextureFormats(TextureFormatCallback,&ddpf); 
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//check if we found a texture format with alpha in it 
if (ddpf.dwSize==0) 
{ 


//no texture format with alpha 
} 


W hat do you do if there is no texture format with an alpha in it?W dll, there isn't much you can do, but | 
dont think this issue will come up, so dont worry about it. 


CREATING THE TEXTURE SURFACE 


T he next step is to create the texture surface using the LPDDS CreateTexturePixelFormat function from 
D 3D Funcs.h/ D 3D Funcs.cpp. 


//create a 64x64 texture surface 
lpddsTex-LPDDS CreateTexturePixelFormat(1pdd,64,64,&ddpf); 


N ow you ve got the new texture surface, and the only thing left is to fill it with the graphical information 
from a bitmap. 


LOCK AND UNLOCK REVIEW 


U nfortunately, using Getbc and ве1еазе0с wont work in this case (I've tried). Apparently GD | doesnt 
like alpha, so this time, you have to do it manually, which means you have to use 
IDirectDrawSurface7::Lock and IDirectDrawSurface7::Unlock. We covered these earlier in the 
book, but heres a quick refresher. 


HRESULT IDirectDrawSurface7::Lock( 
LPRECT lpDestRect, 
LPDDSURFACEDESC2 lpDDSurfaceDesc, 
DWORD dwFlags, 

HANDLE hEvent 

); 


T he return value, as with almost all DirectX function calls, is an HRESULT, which returns pp. ok if success- 
ful or some DDERR_* value if it fails. 


Of the parameters, 1pDestRect IS a pointer to a RECT that describes the area you are locking. If you want 
to lock the entire surface (and that is what you will do), use NULL in this parameter. 1pDDSurfaceDesc іѕ a 
pointer to a DDSURFACEDESC2, which you send іп to retrieve the locking information. dwF1ags tels 

D irectD raw exactly how you want to lock the surface. һЕуеп isnt supported, so put NULL. 
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HRESULT IDirectDrawSurface7::Unlock( 
LPRECT lpRect 
ys 


Unlock isa lot simpler than Lock. T he return value is an HRESULT again, so check for op. ok. T he 1pRect 
parameter is а pointer to the вест you want to unlock. T he кест has to be the same as the RECT you used 
to lock, so if you use NULL to lock, use NULL to unlock. 


N ow that your memory has been refreshed on Lock/ Unlock, le's explore how you'll use them to write 
to your surface. Н ere is the basic breakdown of the code, minus the actual writing of the pixels: 


//set up the surface desc 

DDSURFACEDESC2 ddsd; 

DDSD_Clear(&ddsd); 

//lock the surface (lpddsTex is the texture surface) 
lpddsTex-»Lock(NULL,&ddsd,DDLOCK WAIT,NULL); 
//retrieve the pitch and the pointer to surface memory 
LONG IPitcheddsd.lPitch/sizeof (WORD) ; 

WORD* pSurface-(WORD*)ddsd.lpSurface; 

ИИ ИИ ИИ 

//do whatever drawing here 

ИИ ИИ TT TTT 

//unlock surface 

lpddsTex-»Unlock(NULL) ; 


A brief note about 1Pitch and pSurface: these correspond to the 1Pitch and 1psurface members of 
DDSURFACEDESC2, and they let you write directly to a surfaces memory buffer. pSurface is the pointer 
itself, and it's a void*, because Lock works on all manner of surfaces, which might have different bits per 
pixel. 1Pitch is the length of a scan line, in bytes. It might or might not be the actual width of the sur- 
face, so always use 1Pitch instead of the width. 


You'll notice that | cast psurface to WORD* (WORD is the same as unsigned short). | did so because you 
are primarily working in 16-bit color, and a word has 16 bits, which makes it really easy to use pSurface 
as an array. 


| also divided 1Pitch by sizeof(WoRD) (which is 2) so that 1Pitch now measures the size of a horizon- 
tal row of pixels in мокоѕ rather than bytes. T his has some important ramifications. For example, this is 
how to read and write a pixa: 


//read pixel 
WORD pelepSurface[x*y*lPitch];//retrieve pixel at x,y 
//write pixel 
pSurface[x*y*lPitch]20;//set pixel at x,y to 0 (black) 
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Pretty simple, right? N ow you can read and write pixels on the lowest level DirectX allows, and you can 
now load your image onto a texture surface, even with the alpha information. 


LOADING FIXEL DATA 


You will load pixel data by loading the image into a caDI Canvas object (which you cant BitB1t directly, 
but it's good at loading graphics anyway), determining which color to use as the transparent color (black 
is easiest), locking the surface, and converting the pixels in the сотСапуаз to the format of the surface 
using ConvertColorRef from D DFuncs. You have to add just a little bit of code, because of the 

alpha information. 


T һегеѓоге the code for converting information on a cGDICanvas onto a texture surface looks something 
like the following: 


//variables 

COLORREF crColor; 
COLORREF crTransparent; 
int x,y; 

DWORD ddColor; 

CGDICanvas gdic; 

//load the image 
gdic.load("texture.bmp"); 
for(y=0;y<TEXHEIGHT; у++) 
{ 


for (x=0;x<TEXWIDTH; x++) 
{ 
//grab color 
crColor=GetPixel(gdic,x,y); 
//convert color 
ddColor=ConvertColorRef(crColor, &ddpf) ; 
//check for transparency 
if(crColor!=crTransparent) 
{ 
//add non-transparent alpha value 
ddColor |=ddpf.dwRGBA1phaBitMask; 
} 
//set pixel оп surface 
pSurfaceLxty*1Pitch]=(WORD)ddColor; 
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Place this code (or something very similar) between the surfaces Lock and Untock. T he texture will be 
properly loaded onto the surface, and you will be nearly ready to start rendering it. 


RENDER STATES 


You have one last stop to make before you actually can do transparency in D 3D, and that 15 letting 
Direct3D know what you are doing— namely, that you want to use its alpha testing capabilities. For you 
to do so | must introduce a new method of IDirect3DDevice7— SetRenderState. 


HRESULT IDirect3DDevice7::SetRenderState( 
D3DRENDERSTATETYPE dwRenderStateType, 
DWORD dwRenderState 

ys 


T his function returns озо ок on success and D3DERR_* values on failure. awRenderStateType specifies 
which render state you want to set, and dwRenderState specifies what you want to change the render state 
to. Confused? I'm not surprised. It's a pretty vague explanation for a pretty vague concept. 


Direct3D is a state machine, which is sort of like being a big struct with a whole bunch of members, 

where the value to which any of these members are set changes the way in which it operates. For example, 
one member might control what type of lighting or shading to use, or whether to use shading at all. T his 
is what render states are— just little values stored who-knows-where that affect the behavior of D irect3D. 


U p until now, you've been using the default values of all the render states. T his was fine for what you were 
doing, but it's no longer sufficient, because you want to make use of alpha stuff as transparency. Y ou need 
to change three render states: D3DRENDERSTATE, ALPHATESTENABLE, D3DRENDERSTATE_ALPHAREF, and 
D3DRENDERSTATE, ALPHAFUNC. 


T he first, D3DRENDERSTATE, ALPHATESTENABLE, [5 a воог that specifies whether or not alpha testing is 
used. T he default value is FALSE, so you must set it to TRUE. M ake sure you use capital letters, since the 
BOOL is not the same as 2001. 


N ext, D3DRENDERSTATE. ALPHAREF Contains a reference alpha value (from 0 to OxFF) against which you 
will be testing the textures alpha values. То this render state, you will assign 0x7F.T his value is of particu- 
lar importance because of the 1:5:5:5 format, which has only a single bit for alpha. If the alpha bit is 0, 
the actual alpha (in the 0 to OxFF range) is 0. If the alpha bit is 1, the actual alpha is 0x80, which is 
greater than your alpha test value. 


Last, D3DRENDERSTATE_ALPHAFUNC needs an enumerated type called озосмр, which contains values like 
D3DCMP_NEVER, D3DCMP_ALWAYS, and D3DCMP_GREATER. Т he default value is D3DCMP_ALWAYS, SO you need 
to change it to D3DCMP_GREATER. 
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T he following is the code to set all your render states for alpha testing: 


lpd3ddev-»SetRenderState(D3DRENDERSTATE ALPHATESTENABLE, TRUE) ; 
lpd3ddev-»SetRenderState(D3DRENDERSTATE ALPHAREF,0Ox7F) ; 
lpd3ddev-»SetRenderState(D3DRENDERSTATE ALPHAFUNC,D3DCMP. GREATER) ; 


W ith the render states set, Direct3D is ready for your alpha test rendering. N ow just supply a triangle 
strip with the proper vertices and set 1Direct30Device7' texture, and you can blit a partially transparent 
sprite, just like you did in D irectD raw (except that using Direct3D is a ton faster). 


SETTING UP VERTICES 


Since you are basing the rendering of a tile on its center, you want to be able to do something similar for 
your sprites— that is, you want to have anchors of а sort. Figure 25.4 shows the basic layout of the 
bounding rectangle. You can easily supply this information within the image itself by adding an extra col- 
umn on the right and an extra row on the bottom and placing some sort of control pixel for centering 
there, just as you did for ctileSet.W hen rendering, you use the entire texture, so there is no need to have 
the width and height indicated with these control pixels. Figure 25.5 shows what | mean. 


Figure 25.4 
Vertex information 
(x-anchorx,y-achory) (x-anchorx+T EXW IDTH,y-anchory) for a sprite 
Ф Ф 


ө 
(х,у) 


(x-anchorx,y-anchory+T EX HEIGHT) 
(x-anchorx+T EXW IDTH,y-anchory+T EX HEIGHT) 


THE MUCH-ANTICIPATED 1503D 


Figure 25.5 
Anchor information for sprite 


Figure 25.6 shows the four vertices and two polygons that make up the triangle strip needed to make up 
the sprite, and Figure 25.7 shows the texture coordinates corresponding to these points. You will use all 
this information to display the sprite on-screen. 


Figure 25.6 


Triangle strip for 
a sprite 


EXHEIGHT) vá 
(x-anchorx+T EXW IDTH,y-anchory+T EX HEIGHT) 


E77 
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Figure 25.7 


Texture coordinates 
(x-anchorx,y-achory) (x-anchorx+T EXW IDTH,y-anchory) for a sprite 


V1 
(0.0,0.0) 


(х-апсһогх,у-апсһо! 
(0.0,1.0) V3 №4 (1.0,1.0) 
(x-anchorx+TEXW IDTH,y-anchory+TEX HEIGHT) 


ЖП TRANSPARENCY EXAMPLE 

IsoH ex25 3.cpp is the 3D transparency sample program (see Figure 25.8). It is based on 

IsoH ех25 2.cpp, with the addition of some code that loads a sprite texture and shows a scene of isome- 
ric tiles with the sprite in the center of the screen, so you can see that it is indeed a partially transparent 
texture. All of the code in this example has been shown before, so | wont repeat it here. 


Figure 25.8 


ІѕоН ех25 3.cpp,the 3D 
transparency sample 
program. 
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N ow you have the ability to do in D irect3D all that you have done in D irectD raw. You can blit tiles and 
sprites. In D irectD raw, you would have been totally happy with just this. H owever, this is 3D, and there 
are a lot more options available to you now, and you have а new set of difficulties to overcome. 


DYNAMIC LIGHTING 


One feature you can add to something rendered with Direct3D is dynamic lighting. You wont actually be 
using the Direct3D lighting mechanism (you'll be doing it yourself), but since you can change the colors 
of a vertex and have portions of a texture appear brighter or dimmer, you can certainly do some cool 
"lighting" effects. 


T he only thing you need to change is the color of the vertex, so in your calls to vERTEX. set, you can just 
vary the intensity of the color attributes. Go ahead and load IsoH ех25 4.cpp. T his example is based on 
IsoH ех25 2.cpp, with only minor modifications to Prog Loop. 


void Prog Loop() 

{ 
//clear the viewport to black 
]lpd3ddev->Clear(0,NULL,D3DCLEAR_TARGET,0,0,0); 
//grab the mouse position 
POINT ptMouse; 
GetCursorPos(&ptMouse) ; 
//convert mouse position to floating point values 
D3DVALUE MouseX=(D3DVALUE) рЕМоиѕе. х; 
D3DVALUE MouseY-(D3DVALUE)ptMouse.y; 


T he area around the mouse pointer will appear lit up compared to the rest of the screen. In order to make 
that happen, though, | first needed the mouse position— hence the call to GetCursorPos. Since D 3D 
deals with floating-point values, | converted the mouse position into D3DVALUE'S Моизех and Mousey. 


//declare vector x and y for lighting calculations 
D3DVALUE VertexX; 

D3DVALUE VertexY; 

//distance 

float distance; 

//start the scene 

lpd3ddev-»BeginScene(); 


Also, I'm using a few extra variables for lighting calculations. T he calculations are based on the distance of 
a vertex from the mouse. vertexx and Vertexy contain the coordinate of the vertex, and distance iS 
used to calculate the distance (in pixels) from the mouse pointer to the vertex. 
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//center positions 

D3DVALUE CenterX,CenterY; 

// loop through пар 

for(int y=0;y<MAPHEIGHT ; y++) 
{ 


for(int x=0;x<MAPWIDTH;x++) 

{ 
//calculate world coordinates for center of tile 
CenterXx=(float ) (x*TILEWIDTH+(y&l)*(TILEWIDTH/2)); 
CenterY=(float) (y*(TILEHEIGHT/2)); 


T his is the normal stuff that plots the tiles using the staggered plotting equation. It doesnt change a bit. 


//set up the vertex 

//ч 

VERTEX Set(&vert[0],CenterX-TILEWIDTH/2, 

CenterY,D3DRGB(1.0,1.0,1.0),0.0,0.0); 

//distance calculation 

VertexX-vert[0].sx; 

VertexY-vert[0].sy; 

distance-sqrt((VertexX-MouseX)*(VertexX-MouseX)-* 
(VertexY-MouseY)*(VertexY-MouseY))-*1.0; 

//max distance of 128 

if(distance>128.0) distance=128.0; 

//convert distance to 0.0 to 0.5 

distance/=256.0; 

//change color 

vert[0].color-D3DRGB(1.0-distance,1.0-distance,1.0-distance); 


And heres the lighting calculation for the first vertex. First grab the x- and y-coordinates of verto], and 
then do the distance calculation with the mouse position. N ext, make sure that you damp the distanceto a 
maximum value (in this case, | picked 128 as the maximum distance). So, a vertex can have a "distance" of 
anywhere between 0.0 and 128.0 from the mouse. N ext, convert this number to a number between 0.0 

and 0.5 by dividing by 256. Since you specify color as being between 0.0 and 1.0, this is necessary if you 
intend to use some sort of lighting. Finally, set the color of the vertex, all components set to 1 .0-dis- 
tance, 50 that a vertex at distance 0 will have a color of 030RGB(1.0,1.0,1.0), or pure white, and a 
vertex at or beyond the maximum distance will be at 030RGB(0.5,0.5,0.5), or dark gray. 


//v2 
VERTEX Set(&vert[1],CenterX, 
CenterY-TILEHEIGHT/2,D3DRGB(1.0,1.0,1.0),1.0,0.0); 
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//distance calculation 

ҮегбехХ-уег%Г11.5х; 

VertexY=vertLll.sy; 

distance=sqrt((VertexXx-Mousex )*(Vertexx-Mousex )+ 
(VertexY-MouseY)*(VertexY-MouseY))-*1.0; 

//max distance of 128 

if(distance»128.0) distance-128.0; 

//convert distance to 0.0 to 0.5 

distance/=256.0; 

//change color 

vert[1].color-D3DRGB(1.0-distance,1.0-distance,1.0-distance); 

//УЗ 

VERTEX Set(&vert[2],CenterX,CenterY-TILEHEIGHT/2, 

D3DRGB(1.0,1.0,1.0),0.0,1.0); 

//distance calculation 

VertexX-vert[2].sx; 

VertexY-vert[2].sy; 

distanceesqrt((VertexX-MouseX)*(VertexX-MouseX)-* 
(VertexY-MouseY)*(VertexY-MouseY))-*1.0; 

//max distance of 128 

if(distance>128.0) distance-128.0; 

//convert distance to 0.0 to 0.5 

distance/=256.0; 

//change color 

vert[2].color-D3DRGB(1.0-distance,1.0-distance,1.0-distance); 

//\4 

VERTEX Set(&vert[3],CenterX-TILEWIDTH/2, 

Сепфегу ,D3DRGB(1.0,1.0,1.0),1.0,1.0); 

//distance calculation 

VertexX-vert[3].sx; 

VertexY-vert[3].sy; 

distance-sqrt((VertexX-MouseX)*(VertexX-MouseX)-* 
(VertexY-MouseY)*(VertexY-MouseY)) ; 

//max distance of 128 

if(distance>128.0) distance-128.0; 

//convert distance to 0.0 to 0.5 

distance/=256.0; 

//change color 

vert[3].color-D3DRGB(1.0-distance,1.0-distance,1.0-distance); 

//render the triangle strip 

LPD3DDEV_DrawTriangleStrip(lpd3ddev,vert,4); 
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} 
} 
//end the scene 
ТраЗааеу- > Епаѕсепе( ) ; 
//flip 
lpddsPrime-»Flip(NULL,DDFLIP WAIT); 


} 


Do the same lighting calculations for the other vertices and then draw the triangle strip as normal. T he 
end result looks like Figure 25.9. You can put a light just about anywhere, or even have multiple lights like 
this (perhaps torches or something). You can even vary their intensity to make them flicker, and get some 
really neat lighting effects. D on't be afraid to experiment. 


Figure 25.9 


IsoHex25 4.cpp; some 
light is shed. 


HEIGHT MAPPING 


In 2D, your isometric worlds have been horribly flat. Sure, there may be trees or units or other things that 
“stick up” out of the map, but the terrain itself is flat and boring. 


D irect3D 5 entire job is to make things that look 3D. So, it's only fitting that you can use it to give your 
isometric maps an illusion of depth, even within an isometric projection. T his method is called haght map- 
ping. It takes information from a grid of heights and applies it to the vertices of your tiles. In 150 3D, this 
is very easy, since “up” goes in the same direction as "north." For example, if a vertex is 32 pixels “ир, 
you just subtract 32 from its y-coordinate. If it's 32 pixels down, you add 32 to y. 
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Of course, in order to make the height map look right, you need to make neighboring tiles share vertices 
with their neighbors. T he easiest way to do so is to use a diamond map (since it is so similar to a rectangu- 
lar grid) and place another grid on top of it that keeps track of the lines between the tiles and the inter- 
sections of those lines. If you're using another type of map, you just have to be more careful about keeping 
heights matched between tile vertices. 


NOTE 


A 20X20 diamond map has 21X21 lines, because there is an extra line at the end of the 
map as well as before each tile row/column. 


Н aving said that, go ahead and load 150Н ех25 5.срр, shown in Figure 25.10. It is based on IsoH e25 2 
and shows a random height map. T his example combines a small amount of lighting (higher vertices are 
more lit than lower vertices) and has a variable-height terrain. N ormally, you wouldnt have such rugged 
terrain, but | wanted to accentuate what you can do with height mapping. 


Figure 25.10 
IsoHex25 5.срр 


T he following code sets up the height map. T he height map itself is an array with a first dimension size of 
MAPWIDTH+1 and a second dimension size of MAPHEIGHT+1. 
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//set up the height map 
int x; 

int y; 

// loop through x 

for (x=0;x<=MAPWIDTH; x++) 
{ 


//loop through у 

for (y=0;y<=MAPHEIGHT ; y++) 

{ 
//assign random value 
HeightMapLx]lyJ=(float) (rand()232) ; 


T his is a simpleenough bit of code. Loop through all the positions in the height map, and assign them a 
random value of 0 through 31. After the map is initialized, the only other major change to this program is 
in Prog. Loop, during the actual rendering. 


// loop through map 
for(int y=0;y<MAPHEIGHT; y++) 
{ 
for(int x=0;x<MAPWIDTH;x++) 
{ 
//calculate world coordinates for center of tile 
CenterX-(float) ((x-y)*(TILEWIDTH/2)+320) ; 
CenterY-(float) ((x+y)*(TILEHEIGHT/2)); 
//set up the vertex 
//ч 
VERTEX Set(&vert[0],CenterX- TILEWIDTH/2,CenterY 
-HeightMapLx]Ly+1],D3DRGB(1.0,1.0,1.0),0.0,0.0); 
vertL0].color=D3DRGB(0.5+HeightMapLx]L[y+1]/64.0, 
0.5«-HeightMap[x1Ly*11/64.0,0.5*HeightMap[x]Ly*11/64.0) ; 


//v2 
VERTEX Set(&vert[1],CenterX,CenterY-TILEHEIGHT/2 

-HeightMapLx]Ly],D3DRGB(1.0,1.0,1.0),1.0,0.0); 
vertL1].color=D3DRGB(0.5+HeightMaplx]ly]/64.0, 
0.5+HeightMap[x]Ly]/64.0,0.5+HeightMapLx]Ly]/64.0); 


//v3 
VERTEX _Set(&vert[2],CenterX,CenterY+TILEHEIGHT/2 
-HeightMap[x+l][y+1],D3DRGB(1.0,1.0,1.0),0.0,1.0); 
vert£2].color=D3DRGB(0.5+HeightMap[x+l][y+1]/64.0, 

0.5+Hei ghtMap[x+l][y+1]/64.0,0.5+HeightMap[x+l][y+1]/64.0); 
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//\4 
VERTEX Set(&vert[3],CenterX-TILEWIDTH/2, 
CenterY-HeightMap[x-11LyJ, D3DRGB(1.0,1.0,1.0),1.0,1.0); 
vert[3].color-03DRGB(0O.5*HeightMap[x*11[y1/64.0, 
0.5*rHeightMap[x*11[y1/64.0,0.5*HeightMap[x*11[y1/64.0) ; 
//render the triangle strip 
LPD3DDEV_DrawTriangleStrip(|lpd3ddev,vert,4); 


} 


T here is a change to each call to veRTEX_Set to incorporate the appropriate Hei ghtMap value, subtracted 
from the y-coordinate. After each vertex is set up, a calculation is done based on the height of the vertex 
to determine the color of that vertex. All in all, it’s a pretty simple example, but it looks pretty sweet. 
Play around with it. 


TILE SELECTIONS MOUSEMAPPING 


So, now that you've seen what Direct3D makes very easy, it's time for the other shoe to drop. You may have 
looked at the height map example and wondered, “Н ow the heck do | use a М ouseM ар on this?” T he 
short answer is, you dont use a M ouseM ap in ISO 3D. T he long answer is, you do use a M ouseM ap, just 
not one like you are used to. Instead of using a small M ouseM ap that is repeated across the tilemap, you 
will be constructing a full-screen M ouseM ар. W hy? Because with 150 3D — and especially when you use а 
height map — no set area is taken up by a tiles pixels. You will counteract this situation by having an extra 
surface that Direct3D will write your M ouseM ap onto. 


One of the properties of isometric maps is that the x-coordinates align perfectly, even when you use a 
height map, since the z-coordinate affects only the y and leaves the x alone (see Figure 25.11). You can 
use this property to your advantage, because it divides the map into horizontal strips. T his makes part 
of mousemapping easy, because you can narrow down which tiles the mouse is on, depending on the 
mouses x position. 
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Figure 25.11 


Alignment of 
X-coordinates 


U nfortunately, the same cannot be said for the y position, because in a height map, it can vary widely. 
T his is the part you have to do. T he simplest solution that | have found is to assign a number to each 
row, starting with the number 1 for the first row (0 means "off the map"), and keep adding 1 to this 
number for additional rows. 


| should point out that these are horizontal rows, not the diagonal rows you find on a diamond map. For 
Slide and staggered maps, calculating which row a tile is on is easy, since it is just Марү+1. For diamond 
maps, it 15 MapX+MapY+1. 


So, why not give each tile its own color? Well, you can do that, too, but it limits your maps size. In 16bpp, 
you have 65535 colors (not counting 0). T his allows a map no larger than 255x255 if you are using the 
map colors strictly for tiles and not for object selection. In the one-color-per-row solution, you can have as 
many as 65535 rows. In a diamond map, this means that up to a 32767x32767 map is supported, and in 
other styles of map, up to 65534 rows are supported. Since you are unlikely to even come dose to these 
limits, Га say that one color per row is a good long-term solution. 


You are left with only one problem: converting a row number into a color. Since Direct3D uses the 
D3DRGB macro to construct colors, you'll have something of a hard time converting. As luck would have it, 
the D3DCOLOR type is just a омово with 8 bits set aside for each of alpha, red, green, and blue So, you can 
construct a color manually and guarantee that it will be unique for the row. In order to do that, however, 
you need to do some bit shifting. 


You аге іп 16-bit mode, meaning either 5:6:5 or 5:5:5, and озосогок is 8:8:8, so you must ignore the 
2 to 3 bits of each color component when constructing your colors from row numbers. T his isnt really 
a big deal. 
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//5:6:5 

//dwRow is row number 

DWORD dwColor; 

DWORD dwBlue=(dwRow & Ox1F)<<3;//and with mask, shift right by 3 
DWORD dwGreen=( (dwRow>>5)&0x3F)<<2;//and with mask, shift right by 2 
DWORD dwRed=( (dwRow>>11)&0x1f)<<3;//and with mask, shift right by 3 
//construct the color 

dwColor=(OxFF<<24 )+(dwRed<<16)+(dwGreen<<8)+dwBlue; 


H eres the equivalent code if you're unlucky enough to still have а 5:5:5 card (theres no shame in having 
an old compute’): 


115555 

//dwRow is row number 

DWORD dwColor; 

DWORD dwBlue=(dwRow & Ox1F)«43;//and with mask, shift right by 3 
DWORD dwGreen=( (dwRow>>5)&0x1F)<<3;//and with mask, shift right by 3 
DWORD dwRed-((dwRow»»10)8&0x1f)««3;//and with mask, shift right by 3 
//construct the color 

dwColor=(OxFF<<24 )+(dwRed<<16)+(dwGreen<<8)+dwBlue; 


It seems silly, really. You take a number and convert it to a озосогов, which Direct3D converts into the 
surfaces pixel format (it winds up as the same number you encoded in the first place). 


So, how do you read this number? Simply lock the surface you are using for the M ouseM ap, and read the 
color at Mousex, Mouse. It's just that easy. From here, you can use the vertical strip that Mousex is in, and 
use the row number, and figure out which tile you are on. ГП let you figure out how on your own. 


If you want to include object selection in your М ouseM ap, you must do only a few things. First, you must 
have a monochrome version of the sprites texture (white where the image exists and black where it does 
not), which you load just like any other sprite texture (that is, alpha information). N ext, you set aside one 
of the color bits as an indicator of an "object" (usually, this will be the highest red bit). Finally, you 

draw this texture on your additional rendering target. T his makes object selection a cinch! It does limit 

the number of objects, but if you have more than 32,000 objects, there's really nothing | can do to help 
you make it fast! 
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SUMMARY 


Weve touched on many subjects in this chapter without going deeply into any, because the information 
found herein relies entirely on the foundation of earlier chapters. For example, | didnt discuss how to do 
coastlines or roads on ап 15030 map because you're smart enough to be able to translate the 2D version 
to the 3D version, and | dont want to insult your intelligence or unnecessarily repeat subject matter. 
Everything is moving to 3D now. For a while, isometric graphics were holding out in 2D land. As time 
progresses, doing so will be harder and harder, so it's best to accept the inevitable and just go to 150 3D — 
but not before you have mastered the fundamentals of 1SO 2D. 
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t looks like weve reached the end of the book. | hope! havent left you hanging too much; | tried 
my best to cover all the bases adequately. If | haven't, | sincerely apologize, and | promise to make 
it up to you. 


| started out easy, with basic W IN 32 coding. It was by no means a comprehensive lesson in W IN 32. | 
didnt talk about a whole bunch of stuff, including multithreaded programming, using controls such as 
buttons and textboxes, and so on. T hen | moved into DirectX — namely, DirectDraw and DirectSound, 
| purposely didnt cover Direct Input, DirectShow, DirectPlay, DirectMusic, and any other 
DirectSomethings. | just put in what | thought was important. You might want to get a more wall- 
rounded DirectX education. Also, | used DirectX 7 instead of 8, so you'll probably want to update to 

a newer version at some point. 


With a firm foundation in place in W IN 32 and DirectX , | got into the nuts and bolts of isometric graph- 
ics, the various types of maps, how to scroll, and object placement and selection. All of this stuff works 
mostly the same по matter what platform you're programming for or what type of game you're making. 


N ext, it was time for a bit of optimization, containing some of the wackiest code I've ever written. As a 
side note, | dont actually write code like what you've seen in this book. М y usual approach to coding is a 
lot more object-oriented, but | was trying to write code that was pretty easy to read (| know my normal 
code takes an interpreter to decipher). 


| touched on isometric art issues, tile slanting, and tile ripping. | also touched on world building and artifi- 
cial intelligence. | truly wish | could have done more with Al, but | am not exactly a master of it (my skills 
lie mainly with graphics), and besides, there are entire volumes written about Al that cover it much better 
than | could. 


Finally, | gave you a taste of Direct3D and showed you a few neat things you can do with 3D graphics to 

simulate 2D graphics while not overly complicating the rendering. You may be alarmed that | covered it in 
only two chapters. W ell, in my defense, | can say that all the rest of the knowledge about isometric engines 
is in the chapters leading up to the Direct3D chapters. 


If | didnt answer all your questions, or if | brought up more, come find me. | ve got aW eb site dedicated 
to support of this book (http:/ / www.isohex.net). You can also e-mail me at tanstaafl@ gamedevnet. 111 
either try to answer your concern myself or refer you to aW eb page that answers your question. 


And hey, you can always come find me at the GDC or XGDC. I'm the fat guy with a crew cut wearing a 
GameD wne t-shirt. 
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CURRENT TRENDS 


T he entire world, it seems, is programming 3D games, although the isometric perspective is still quite 
popular, mainly for strategy and role-playing games. T hese games too are moving into 3D, even if that just 
means using 3D acceleration to render in 2D. 


W hy is this so?T here are a number of factors. First, publishers wont put out any more 2D games except 
as value titles (things like “1,000 Games" packages that you see on the rack in department stores and elec- 
tronics stores). Even in value titles, they are usually bundled with a bunch of other 2D games. 


Second, technology is continuing to grow by leaps and bounds. At the beginning of 2000, | had aK 6-2 
300M H z computer with a lousy video card. By the end of the year, | was using an Athlon 700M H z with 
a Geforce 2 GT S, which still isnt top of theline. (If youre reading this any significant amount of time in 
the future— that is, 2002 or later— please try not to snicker at my puny computer.) T he theory is that a 
big-title game should make use of the most modern technology available. If youre anything like me, you 
understand that not all games nea to be 3D. U nfortunately, the rest of the world disagrees— or, at least, 
it seems to. 


T hird, gamers are like drug addicts; they need something new and better with each game they buy in order 
to get their high. T his is especially true of first- and third-person shooter gamers. G amers who are into 
strategy games and R PGs usually dont require that all the graphics be top-notch. T he trick is to reach this 
group with your product. Since a publisher wont publish a 2D game, this makes it a little bit tougher, but 
that's where the W eb comes in. 


WHAT IES AHEAD 


W hy are you still reading, when you should be coding а game?T heres no time like the present, you know. 
| dont exactly have a crystal ball to look into the future and anticipate all the problems that are coming. 


W hat | think is ahead: a more complete move to 3D. If DirectX 8.0 is any indicator, traditional 2D will, 
for the most part, be dead. W hy blit partially transparent rectangles when you can texture map while using 
dynamic lighting and height mapping?T he stuff that is currently new in video card technology will 
become commonplace (if the feature is used a lot) or will go away (if no one uses it). Т his is the way of 
things in technology. 
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W hat's ahead for you is totally up to you. Following are just а few bits of wisdom to ponder: 


= It doesnt happen overnight. It takes a certain mind-set that not everyone has to be а solid game 
programmer. Y ou must be creatively logical and logically creative. Both hemispheres of your brain 
must be fully engaged. 

= Programming is programming. T he rest is just syntax. Currently, | program in С++ using M icrosoft V isual 
C++ 6.0 and make use of the DirectX API.T his has not always been so and will not always be so. | have no 
particular loyalty to any operating system, compiler, or АРІ. | used to program in BASIC and Pascal. | only 
moved to C++ in 1998. Lately, I've been learning to program for the C ybiko, so as of this moment, | am a 
cross-platform programmer. H егес the point: you dont want to bea “W indows programmer" or a "D irectX 
programmer" — you want to be a proyamme. Programmers solve the problems of the day using the tools of 
the day, and they create the problems of tomorrow (job security, you know). 

= Games are supposed to be fun. You probably already know that, but some people forget and they need to be 
reminded. Also, if you're just doing this as a hobby, game programming should also be fun. If neither the 
game nor making it is fun, stop and move on to something else. You can always take up gardening. 

= Start small. | ve seen it a thousand times: some young dude gets a compiler and a book and gets it into his 
head that he can program the greatest game ever with full 3D graphics, multiplayer, surround sound, and so 
on. T his just doesnt happen. Beware of “feature creep,” where you start adding ideas to the program in the 
middle of making it, thus guaranteeing it will never be done. 

= Finish what you start. T his goes along with the previous item. W hen you start small, finishing is easier, pro- 
vided that you keep feature creep in check. Also, by finishing a project, you boost your morale a great deal, 
which makes finishing other projects easier. O h, and by “finished,” | dont mean "playable" or "fully function- 
al.” | mean a game that has been polished to publishable or near-publishable quality. 

= Dont be afraid to fail. T his is really important. If something is unfamiliar to you, try it out. Attempt to 
muddle through it. Leave a long trail of runtime errors and page faults and blue screens of death in your 
Wake. Be patient. 

= Don't be afraid to get help. Buy books. Buy lots of books. Read them. D o the sample programs. M odify 
the sample programs until they break (that's what they're for). Go to Web sites and look for articles, post 
your questions on message boards, go to game programming chat rooms, find the game programmers on ICQ 
and AIM . N o matter what your programming levd, there are programmers better than you are (apologies if 
this book happens to get into the hands of the best programmer in the world). 


“N ever give up; never surrender!” "D o, or do not. T here is no try." (Insert words of encouragement here) 
All right...enough is enough. Stop reading and go make a game or something. Shoo! 
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n this appendix, l'II show you how to load the examples into your compiler so that you can build 
them and run them. | wrote all the examples for this book using V С++ version 6. T his isnt to say 
that they wont work on other versions of V C ++ or that you cant get them to work on other compilers. 


To demonstrate the loading of an example, | will use 150Н ex1 1.срр. | have chosen this example because 
it contains only one file. At thetop of the main file (the only file in this case), you can see a number of 
commented lines. 

/ ЖЖЖЖЖЖЖЖЖЖЖЖЖЖЖЖЖЖЖ KK KK KKK KKK KK KK KKK KKK KKK KK KKK 

TsoHexl_l.cpp 

Ernest S. Pazera 

08APR2000 

Start a WIN32 Application Workspace, add in this file 


No other libs are required 
KR KKK KKK IK KK KKK KKK IKK KK KK KKK KKK KK KK KKK KKK KKK KKK | 


Within this area, | have placed applicable information about the example the name of the file the name of 
the author (mel), when | wrote it, how to start a project for it, and what other files or libraries are required 
to make the program work. As you get further along, you'll have more than just a single file in your proj- 
ects. You'll never quite get to the level of a real-world project, which can contain hundreds of source files, 
but expect at some point to reach at least half a dozen. 


To load an example into your compiler, do the following: 


1. Start your compiler and select the menu option File, М ew, as shown in Figure A.1.T his brings 
up the dialog box shown in Figure A.2. 
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ITE 2 Figure А.1 
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2. Makecertain you are on the Projects tab. 

3. You can create many different types of projects. M y examples are all W IN 32 applications, so 
click on the line that says W in32 Application, and enter a project name in the Project name 
textbox at the top right (see Figure А.З). 
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т. Магов Visual С++ 


Figure А.З 


Giving a project a name 
(always be sure to select 
WIN 32 Application) 
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4. Click on the OK button. You'll see the dialog box shown in Figure A 4. 
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Figure A.4 
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5. 


М ake certain that the “An empty project.” option is selected, and click on the Finish button 


You will be taken to your new, empty workspace. М ow, copy апу of the needed files into the project's fold 
ег. (T he default location when you install VC ++ is СА Program Files\ M icrosoft V isual 


Studio M yProjects\ P rojetN ama , where P rojetN ame is whatever name you gave your project.) 
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After you have copied the applicable files, you must add them to your project by doing the following: 


1. Select Project, Add To Project, Files, as shown in Figure A.5.T he dialog box shown in Figure 
A.6 will open. 


FigureA.5 
Adding files to a project 


FigureA.6 
The standard file open dialog 
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2. Select whatever .cpp or .h files the example requires, and click on OK. 


You can now examine the files from the FileV iew tab іп the compilers leftmost pane by manipulating the 
tree view (see Figure А.7). 


Figure А.7 
wen карды) B The tree view of files, in which double-clicking on a file 
5-28 IsoHex1_1 files К Ж ; 4744 
Е-Е Source Files displays the file’s contents in the main viewing pane 


М І=оНех1 1.срр 
С Header Files 
( Resource Files 


ma ClassView 


You can build the executable by pressing F7 or by selecting Build, Build. After it is built, you can run it by 
pressing Ctrl+F5 or by selecting Build, Execute. T here are also buttons on the toolbar for these tasks. If 
you run before you have rebuilt, the compiler will ask you if you want things rebuilt (compilers are getting 
smarter and smarter). 


Т hat's really all there is to it, at least until you get into DirectX in Chapter 4 (I'll show you what you need 
to do then). 


CODING CONVENTIONS 


After you spend any amount of time looking at code | have written, you'll notice that | precede the names 
of variables with letters such as “dw” and "Ip" and “п” T his is called Н ungarian notation. | dont follow 
all the convention to the letter, but I've tried to be consistent for the book's sake T able 0.1 lists some of 
the most common prefixes | commonly use. Knowing these will help you when you read M icrosoft docu- 
mentation, because all M icrosoft code uses H ungarian notation. 
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Table A.1 Common Prefixes in Hungarian Notation 


DataType Prefix 
bool b 

char c or ch 
unsigned char (BYTE) uc or by 
short int n 
unsigned short (WORD) М 

int пог | 
unsigned int (DWORD) dw 
Flags f (usually combined with w or dw) 
char* (pointer to a string) Ipsz 
Pointer p 

Long pointer Ip 


M y indentation style is pretty normal. T he contents between a { and a } are indented. T he initial { 15 опа 
new line, as shown here: 


for(int х=0;х<10;х++) 
{ 
//code here is indented 


} 


T his might be а slight change if you're used to indenting in the more traditional C style: 


for(int х=0;х<10;х++) { 
//code here is indented 


} 


| was never very fond of this style (1 used to program in Pascal), because | like to see the ( and } line up 
vertically. T his is just a matter of taste. 


пм Б eee АР K Js um OC 
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n my original articles on the topic of isometric graphics, | also spoke of hexagonal graphics, because 

they were so similar. In this book, | have primarily concentrated on isometric graphics, but | didnt 
want to leave out people who are into hex (and you know who you are). | also wanted all the hex-specific 
stuff to bein one place, where! could just show what differs from iso, for those who are just interested in 
theiso stuff (and | imagine most people are interested in iso rather than hex). 


150 VERSUS HEX 


Depending on the game you're making, there are plenty of good reasons to choose iso over hex, or hex over 
iso. Some games make more sense one way and seem kind of weird when using the other. T his mainly 
boils down to a judgment call on your part. If something isnt working as well using hex, switch to iso to 
see if it's any better. If something just doesnt seem right in iso, give hex а try. 


If you've played tabletop strategy games (many of these games are from Avalon Hill, the ones with little 
cardboard counters to keep track of units), and you like these games, and you want to make a video game 
that is similar, hex is probably your best bet. 


Another reason to use hex rather than iso is that hex is different. All kinds of games use iso, but not many 
use hex. If you want your game to stand out, hex is a way to do it. 


Мінгітіс THE DIFFERENCE? 


T he vast majority of the algorithms for iso can be used for hex, with no change or very little change. 
Generally, about the only thing you'll need to change is the M ouseM ap. Figure B.1 shows what a hex 
M ouseM ap might look like. 
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Figure B.1 


H exagonal M ouseM ар 


Таке a look at 150Н ехВ 1.cpp and its associated files (shown in figure B.2). T his example is the exact same 
code as |soH ех15 1.срр, except with different, hexagonal graphics. T his example shows you exactly how 
easy it is to switch between iso and hex. It also shows that there is nothing you dont already know about 
the rendering of the hexagonal engine. Almost everything is the same. | do suggest that you primarily stick 
to staggered maps for hex, unless you have a good reason not to. 


M oving around the hex map is slightly different than in iso, but it simply involves the renoval of two 
directions (in the case of this tile shape, north and south are those directions). So if you dont move in 
those directions, everything will be OK. 


SUMMARY 


H exagonal graphics and hexagonal engines are nothing but an isometric graphical engine with a rectangular 
block inserted in the middle. | don't mean to belittle hexagonal engines, but this is what they really boil 
down to. T his book's support site (http:/ / www.isohex.net) has a section dedicated to hex games. 
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book about game programming is not complete without a list of other resources you can turn to 

for help. T his appendix mainly lists W eb pages, but I've also included а few books on general 
game programming and other general programming topics. As luck would have it, this book is the only 
book (that | know of) that specifically covers the topic of isometric graphics in games, so | really have no 
competition to speak of. 


SEE THE ЕПТЕНШ 


T he following is a list of W eb sites/ pages that might be of interest to you. You've probably already been to 
several of these in search of knowledge. 


ISOHEX«aNET 
[р / www.isohex net 


T his is my own site, specifically for the support of this book. If you are having trouble with some of my 
code, or are looking for errata, or have a neat isometric game or tutorial or new technique you've written, 
come on by. T he purpose of IsoH ex.net is to build upon the content in the book, and you can contribute 
if you like. 


| will also keep a list of good sites for isometric information at this site. 


GAMEDEV:NET 
http;/ Г www.gamede.né/ gamedev.asp 


Apologies to D ave Kevin, John, and M ike for not listing this page first. GameD e.ne is the best game pro- 
gramming W eb site ever created. | know this because! am one of the members of the company that main- 
tains this site. 

http:/ / www.gamedeu.net/ reference/ list.asp?categoryid- 44 


T his specific GameD ev link is for the list of isometric and other tile based programming articles on the 
site. А few old ones are by me Т here's lots of good stuff there. 


XTREME GAMES 

http:/ Г www.x games3 d.com/ 

T his is Andre LaM othes site. If you dont know who Andre LaM othe is, well, you should. H es the series 
editor for this book and series; his name is оп the cover. Н es the guy who wrote Tricks of theWindows б ame 


Progamming G urus, as well as a number of other books about game programming. And he plays М etallica 
M IDIs on his page. 
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TSOMETRI1X 

http;/ Г www.isom&rix .0г0 

Comprehensive resources on isometric algorithms and graphics аге few and far between. Before | created 
ISOH ex.net, this site, run by Yanni D eliyannis, was really the only one Isometrix is an iso engine based on 


an older D O S engine by Jim Adams. If you dont know who Jim Adams is, just wait. Н e has a book in 
this series that should be coming out soon. 


HiT THE BOOKS 


It would be great if you only needed the information in this book and never needed to go to another. 
Unfortunately, it doesnt work like that. And yes, | know that these books are expensive. Н ere are a few 
selections from my own library I'd like to share. 


LaM othe, Andre. Windows 6 ame Programming for D ummies Indianapolis: ID G Books, 1998 


T his is a great book for learning DirectX and W IN 32 programming (it goes into greater detail than | was 
able to). 


(ӘМ othe, Andre. Tricks of the Windows G ame P rogamming G urus Indianapolis: Sams Publishing, 1999 


Although much of the subject matter іп this book and the иттіє book is the same or similar, there is 
much more detail in this one Also, the second edition will cover more 3D graphics. 


DROP ME A LINE 


Web sites come and go, as do Internet service providers. If you want to get in touch with me, your best bet 
is probably to e-mail me. For the conceivable future, my e-mail address is tanstaafl@ gamedev.net. | also 
hang out in IRC on afternet, in the  gamedev channd. M y nick isTAN STAAFL. 


And before you feel the need to ask, TAN STAAFL stands for "T here aint no such thing as a free lunch." 
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INDEX 


1Param member, 8 

2:1 ratio isometric tiles, 561 

2D sprites in Direct3D, 670-679 
3D games, 635, 691 

3D transparency example, 678-679 


A 
Adams, Jim, 286, 707 
AddFontResource function, 83 
AddRect function, 452 
AddRef function, 131, 636 
AddTile function, 452 
AddU pdate function, 121-122 
AdjustanchorSpace function, 390, 392 
AdjustScreenSpace function, 390-392 
AdjustWindowRectEx function, 54-55 
AdjustwindowRect function, 53-55 
AdjustWorldSpace function, 390, 392 
agents, 238, 240 
Al (artificial intelligence), 616 
chase algorithm, 618 
elementary, 616-620 
evade algorithm, 618-619 
Pathfinding algorithm, 621-632 
Al_COUNT constant, 274 
ALTERNATE fill mode, 100 
ALTERNATE polygon fill mode, 77-78 
anchor member functions, 393 
anchor point, 246-247, 253 
anchors, 240 
coordinates, 244 
І5ОН ex tilesets, 294-296 
screen-to-view, 264 
tracking, 246 
anchor space, 240, 311 
member functions, 392-393 
AND bitwise operator, 109-110 
animated sprite example 
cleaning up, 256 
main loop, 255-256 
Prog Init function, 254 
setting up, 254-255 
taking control, 256 
applications 
activating or deactivating, 34-35 
checking message queue for waiting 
messages, 8-9 
handle to current instance of, 6 
paused state, 34 
arcade/ action genre, 226-227 
Ari Feldman Web site, 241 
arrays, 481 
tilemaps as, 259-261 
attached surfaces, 153 
axonometric projections, 287 


back buffers, 441 
absence in windowed Direct Draw, 
186-187 
creation of, 152-154, 664 
reasons for using, 153 
backgroundts.bmp file, 414 
back story, 225 
bActive global variable, 35 
bClick global variable, 455 
BeginPaint function, 28, 56 
BeginScene function, 644 
bFlash global variable, 504 
BGR pixel format, 171 
bH ilite member, 276 
BitBld function, 105-109 
ВІТМАРН eight constant, 108 
bitmaps 
blank, 102-104, 117 
compatible, 102 
containing garbage, 103 
deleting, 105 
loading, 155-158 
loading from disk, 103-105 
management class, 115-118 
usage, 104-111 
BITMAPWIDTH constant, 108 
bitmasking, 113-115 
bitwise operators, 109 
combining colors, 110-111 
rules for, 114 
blank bitmaps, 102, 104, 117 
double buffering, 119-122 
size, 119 
blastM ove member, 276 
BldFast function, 158, 179-180 
BLD function and clippers, 179 
blitting 
more efficient algorithm, 420-425 
order in diamond tilemaps, 363 
rectangular area to tile, 571 
rectangular tiles, 300 
reducing number of blits per frame, 
425-433 
reducing overhead, 441-442 
tiles, 247 
blockcount variable, 606 
block variable, 606 
BltFast function, 166-167, 435 
parameters, 436-437 
putting values in parameters, 
437-439 
Bit function, 158-166, 435436 
bMap data member, 450 
bMoveUnit global variable, 464, 
517-518 
bouncing ball demo, 156-158, 
162-163 


Breakout, 230-234 
brushes 
creation of, 69-70 
destroying, 70 
example, 71 
filling area, 70-73 
filling shapes, 101 
handle to, 19 
hatch styles, 70 
outlining regions, 101-102 
solid-color, 69-70 
buffers 
retrieving data into, 183 
size required for, 183 
sound, 198-200 
streaming, 205 
Build, Build command, 700 
Build (F7) function key, 700 


CalcAnchorSpace function, 390, 393 

CalcFringe function, 589-592 

CalcFringeN eighborhood function, 
592-593 

CalcReferencePoint function, 399 

CalcWorldSpace function, 388, 390, 


392 
CALLBACK function, 9 
centering on current unit, 514 
CGDICanvas class, 115-119 
CGDICanvas object, 674 
char buffer, 181 
chase algorithm, 618 
child windows, 23 
chMouseM apLookU p pointer, 332 
Civilization ||, 286 
classes 
bitmap management, 115-118 
identifiers, 134 
Clear function, 642-644 
dear method, 490 
ClearU pdate function, 121 
click-selecting units, 512 
dient area 
area contained in, 52 
clearing, 73 
invalidating portions, 57 
modifying size, 53-54 
repainting, 51 
dient coordinates converting to screen 
coordinates, 186- 187 
ClientToScreen function, 186-187 
clippers, 436 
assigning to surfaces, 183-184 
BldFast function, 179 
BLD function, 179 
full-screen DirectDraw, 187 
not owned by DirectDraw object, 
180 


setting up clipping region, 180-183 
windowed DirectDraw, 187-188 
clipping, 95-101 
clipping regions 
creation functions, 182 
setting up, 180-183 
updating, 443-445 
ClipScreenAnchor function, 324, 334, 
351-352, 357-358 
ClipTile function, 439-441 
CloseH andle function, 212 
closing files, 212 
CMouseMap class, 395-401 
data members, 397-398 
member functions, 398-400 
CMouseMap function, 398 
(~ cMouseMap function, 398 
code, special-case, 340 
coding conventions, 700-701 
color-blended tile slanting, 562-563 
color depths, 60, 139 
color fill on surfaces, 162 
color key, 166-167 
color keys, 163-167 
COLORREF pixel format, 61, 169, 
171-172 
colors 
combining with bitwise operators, 
110-111 
fills, 19 
GDI, 61 
of position on specified HDC, 62 
selection window, 526 
text, 86 
COM (Component Object Model), 
130-131 
COM objects and class identifiers, 134 
compatible bitmaps, 102 
compilers, loading sample programs, 
696-700 
computer games, 223 
constants 
IsoH ex18 3.cpp file, 493, 495-497 
TileMap editor, 265-266 
construction/ destruction functions, 
380-381, 398 
content, double buffering, 119-122 
continents, 611-613 
controls, 229-230 
conversion member functions, 
393-394 
ConvertColorRef function, 175 
ConvertDDColor function, 175 
cooperative level, 135-136 
coordinate system 
diamond tilemaps, 360-361 
slide tilemaps, 305-306 
staggered tile maps, 339-340 
COP (coarse object placement), 459 


copying 
RECT structure, 47 
between surfaces, 162-163 
CopyRect function, 45, 47 
count variable, 486 
CreateClipper function, 180 
CreateCompatibleBitmap function, 
102-103 
CreateCompatibleDC function, 58 
CreateDevice member function, 
638-640 
CreateEllipticRgn function, 92-93, 182 
CreateFile function, 209-210 
CreateFont function, 83-85 
Create function, 399 
CreateH atchBrush function, 70 
CreatePen function, 64 
CreatePolygonRgn function, 93, 182 
CreateRectRgn function, 94, 182 
CreateRoundRectRgn function, 94-95 
CreateRoundRgn function, 182 
CreateSolidBrush function, 69-70 
CreateSoundBuffer function, 198-200 
CreateWindowEx function, 21-23, 
54-55 
CreateWindow function, 21, 54-55 
CRenderer class, 446-448, 468-469 
member functions, 450-452 
RENDERFN function pointer, 448 
utilization functions, 452 
CRenderer class example 
cleanup, 454 
initialization, 453-454 
main loop, 454-456 
CScroller class, 387-395, 435 
data member, 389-390 
member functions, 390-394 
CScroller function, 390 
(-)CScroller function, 391 
CTilePlotter class, 376-377, 382-383 
data members, 379-380 
member function, 380-381 
CTilePlotter function, 380-381, 570 
(~+CTilePlotter function, 380-381 
CTileSet class, 248-253, 435, 453, 539 
extending, 439-441 
member functions, 251-253 
private members, 250 
CTileset object, 414 
CTileWalker class, 386 
data members, 384 
member functions, 385-386 
CTileWalker() member function, 
385-386 
(~CTileWalker() member function, 
385-386 


customizing game play, 229 
CWAVLoader, 215-217 
CWAVL oader class, 213 


D3D (Direct3D), 125 
as 2D renderer, 635 
2Dsprites, 670-679 
basics, 636 
compiling programs, 650 
device creation, 638-640 
drawing objects, 642-649 
dynamic lighting, 679-682 
functions, 661-670 
height mapping, 682-685 
mousemapping, 385-387 
operation of, 635 
rendering, 642-649 
render states, 675-676 
setting up vertices, 676 
surface creation, 637-638 
tile selection, 385-387 
triangles, 635 
viewport creation, 640-649 
d3d8.lib library, 650 
d3d.h header file, 636, 650 
d3dim.lib library, 636 
D3DRENDERSTATE_ALPHAFUNC 
render state, 675-676 
D3DRENDERSTATE_ALPHAREF ren- 
der state, 675-676 
D3DRENDERSTATE_ALPHATESTEN- 
ABLE render state, 675-676 
D3DRGB macro, 644, 686 
D3DTLVERTEX structure, 665 
D3DVIEWPORT7 structure, 640-649, 


663 
DCs (device contexts), 56 
bringing, 70 
current position, 65 
deleting, 105 
memor y, 58-59 
moving information between, 
105-109 
obtaining, 56-58 
placing GDI object in, 59-60 
releasing, 57-58 
DD (DirectDraw), 125, 133-135 
DDBLTFX Clear function, 174 
DDBLTFX ColorFill function, 174 
DDBLTFX structure, 160-162, 164, 
174, 406 
DDCOLORKEY structure, 164-165 
DDFuncs.cpp file, 173, 177, 183, 637, 
661-670 
DDFuncsh file, 173, 183, 661-670 
DDFuncs library, 453 
DDPF Clear function, 175 
ddpfPixelFormat member, 139 
DDPIXELFORMAT structure, 
139-140, 169-170, 171, 643 
ddrawlib library, 130 
DDSCAPS2 structure, 153, 174 
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DDSCAPS BackBuffer function, 174 
DDSCAPS Clear function, 174 
DDSCL_NORMAL mode, 188 
DDSD_Clear function, 174, 637-638 
DDSD_OffscreenSurface function, 174 
DDSD PrimarySurface function, 174 
DDSD PrimarySurfaceWBackBuffer 
function, 174 
DDSURFACEDESC2 structure, 
138-139, 148-149, 154-155, 168, 
185, 637 
ddsCaps member, 150-151 
dwFlags member, 150 
initializing, 144 
meaningful members, 149-150 
setting up functions, 174 
valid members, 150 
DD (DirectDraw) wrapper, 173-176 
Debug configuration, 130 
decibels, 203 
deGBitM ask member, 171 
DeleteO bject function, 70, 85, 95 
deleting 
DCs (device contexts), 105 
from linked lists, 485 
memory DC (device context), 58 
regions, 95 
Deliyannis, Yanni, 707 
DeltaX function, 315 
DeltaY function, 315 
DelteDC function, 58 
destination color keys, 164 
destination surfaces, 253 
Destroy function, 399 
destroying widows, 27 
DestroyMiniM ap function, 545-547, 
550 


devices 
creation of, 663 
DCs (device contexts), 56 
Direct3D creation, 638-640 
independence, 56 
varying coordinate systems, 56 
viewport creation, 653 
viewports, 640-649 
DI (DirectInput), 125 
DiamondMap TilePlotter function, 
362 


DiamondMap TileWalker function, 
368- 369 

diamond shapes, 287 

diamond tilemaps 
blitting order, 363 
coordinate system, 360-361 
diagonal axis, 361 
extending off-screen, 362 
MouseM ap component, 294 
mousemapping, 369-370 
scrolling, 363-364 
TilePlotter component, 294 


tileplotting, 361- 362 
TileWalker component, 294 
tilewalking, 365-369 
digital sound, 191 
Direct3D example, 649-650 
cleanup, 651-654 
global variables, 650-651 
initialization, 651-654 
main loop, 654-655 
Prog Init function, 651-654 
DirectDraw, 634 
clippers, 179-184 
full-screen, 185 
surfaces, 147-177 
windowed, 184-188 
DirectDrawCreateClipper function, 
180 


DirectDrawCreateE x function, 
133-134, 637 
DirectDraw objects 
off-screen surfaces, 147 
primary surface, 147 
secondary surface, 147 
direction keys, 506-508 
DirectSetup, 125 
DirectSound, 191 
control flags, 202-205 
cooperative level, 197-198 
IDirectSound, 196 
DirectSoundCreate function, 196-197 
DirectX 
COM (Component Object Model), 
130 


components, 125 
configuring, 125-130 
D3D (Direct3D), 125, 133 
DD (DirectDraw), 125, 133-145 
Debug configuration, 130 
DI (DirectInput), 125 
DirectSetup, 125 
DirectSound, 191-218 
DM (DirectMusic), 125 
DP (DirectPlay), 125 
DS (DirectSound), 125 
initializing structures, 144 
interfaces, 131 
objects, 130 
Project, Settings command, 130 
reference counting, 131 
Release configuration, 130 
version control, 131 
DirectX 8, 634 
DirectX objects 
releasing, 145 
dir variable, 590 
DispatchM essage function, 26 
display modes 
bit depth, 140 
bits per pixel, 144 
color depth, 139 


enumerating, 136-143 
height, 139, 144 
information about, 138 
refresh rate, 137 
retrieving current, 144 
setting, 153 
VGA, 137 
width, 139, 144 
windowed Direct Draw, 185-186 
distance variable, 679 
DM (DirectMusic), 125 
double buffer 
creation of, 120 
double buffering, 119-122 
blank bitmaps, 119-122 
DP (DirectPlay), 125 
drawing functions, 65-66 
drawing lines, 66-69 
DrawMap function, 307, 308-309, 313, 
355-356, 363 
DrawPrimitive function, 644-649, 654 
dptPrimitiveT ype parameter, 
645-647 
dwVertexT ypeD esc parameter, 
647-649 
IpVertices parameter, 649 
parameters, 645 
DrawText function, 89-91 
DS (DirectSound), 125 
DSBCAP CTRLPAN flag, 204 
DSBCAPS CTRLFREQUENCY flag, 
202 
DSBCAPS CTRLVOLUME flag, 203 
DSBFREQUENCY MAX constant, 202 
DSBFREQUENCY MIN constant, 202 
DSBFREQUENCY ORIGINAL con- 
stant, 202 
DSBPAN CENTER constant, 204 
DSBPAN LEFT constant, 204 
DSBPAN RIGHT constant, 204 
DSBUFFERDESC structure, 199 
members, 199-200 
nSamplesPerSec member, 202 
DSBVOLUME MAX constant, 203 
DSBVOLUME MIN constant, 203 
DSFuncs library, 218 
dsound.library, 130 
DuplicateBuffer function, 208 
duplicating 
sound buffers, 208 
dwBBitM ask member, 171 
dwRBitM ast member, 171 
dwRGBBCount member, 140 
dwRop member, 164 
dwRowCount variable, 430 
dwSize member, 144 
dxguid.lib library, 130, 134 
dynamic lighting, 679-682 


Е 

editing panel, 263-264 

eight-direction structures, 599 

ellipse, 73-74 

Ellipse function, 73-74 

elliptical region, 92-93 

empty method, 490 

empty square, 514 

end game, 222 

EndPaint function, 28, 56 

EndScene function, 644 

engines, І5оН ex versus rectangular, 291 

EnumDisplayM odes, 136-143 

enumerating display modes, 136-143 

EnumTextureFormats function, 
670-672 

EqualRect function, 45, 50 

erase method, 490 

error checking, 135 

evade algorithm, 618-619 

event-driven operating system, 7-8 

even y tilewalking, 346-347 

example programs, loading, 696-700 

extended templates, 245 

extents, 240, 248 

ExtFloodFill function, 70-71 


F 
FAILED macro, 135 
Feldman, Ari, 241 
File, New command, 696 
files 
accessing, 6 
closing, 212 
creation of, 209-210 
opening, 209-210 
reading data from, 211-212 
WIN 32 access, 209-212 
writing data to, 210-211 
filling 
rectangular area, 72-73 
shapes, 101 
fill modes, 77 
FillRect function, 72-73, 103 
FillRgn function, 101 
fills 
color or pattern, 19 
GDI objects, 69-73 
rectangular area, 158 
final game state, 222 
FindPath function, 624-625 
finishing games, 234-235 
Flip function, 153-154 
flipping chains, 147, 153-154 
fog of war, 553 
fonts, 82 
background mode, 85-86 
bringing to device context, 85 
color, 86 
creation of, 83-85 


destroying, 85 
formatting, 89-91 
localization, 85 
logical units, 85 
removing, 83 
temporarily loading, 83 
FOP (fine object placement), 459 
for loop, 485, 528 
formatting text, 89-91 
fortification/ holding position, 
512-513 
found variable, 606, 628, 630 
four-direction structures 
CalcRoad functions, 596-598 
map structure, 594-595 
rendering map location, 595-596 
usage, 598 
frame buffers 
scrolling, 442 
updating, 445 
frame rate lock, 233 
FrameRgn function, 101-102 
frames 
reducing number of blits per, 
425-433 
updating, 528 
free function, 142 
free store, 481 
FringeLookUp array, 588 
FringeLookUp table, 587 
fringes, 579-580 
art requirements, 581-584 
calculating, 589-593 
example, 586-593 
lookup table, 584-585 
map structure, 587 
rendering function, 587-589 
tile zones, 584-585 
full-screen DirectDraw, 185, 187 
function pointers, 378 
functions, 377 
clipping region creation, 182 
construction/ destruction, 380-381 
DDBLTFX structure, 174 
DDSCAPS2 structure, 174 
DDSURFACEDESC2 structure, 174 
Direct3D, 661-670 
IuDirectDraw7 interfaces, 175 
LPDIRECT DRAWSURFACE/7, 
175-176 
map type, 381 
minimaps, 545 
pixel formats, 175 
plotting, 381 
tile size, 381 
FVF (Flexible Vertex Format), 647 


gameDev.net Web site, 287, 706 
game mechanic, 222-223 


game states, 222 


game programs demand on operating 


system and hardware, 6 


analysis of, 223-224 

arcade/ action genre, 226-227 
back story, 225 

commonality, 224 

computer, 223 

controls, 229-230 
customizing play, 229 
definition of, 221 

designing, 224-225 
documentation, 229 

end game, 222 

equipment, 221 

fairness, 223 

features appropriate to, 224-225 
final game state, 222 
finishing, 234-235 

fleshing out, 225 

frame rate lock, 233 

future of, 691-692 

game mechanic, 222 

game states, 222 

icons, 229 

incremental difficulty, 227 
initial concept, 225 
intangible nature of, 221-222 
isometric, 227-229 

learning curve, 229 

levels or waves, 227 
limitations, 235 

mini-map, 230 

necessary win conditions, 228 
necessity of hostiles, 227 
obstacles, 226 

optional features, 224 
planning, 235 

playability, 603 

polishing, 235 

power-ups, 227 

power-up system, 226 
reasons for playing, 222-223 
replayability, 603 

rewards, 227 

rules, 222 

running single frame, 26 
starting player with few units, 228 
story board, 225 

technology and research, 228 
tile-based, 238 

time working on, 235 
turn-based strategy, 228, 492 
user interface, 229 


IsoH ex19 1 file, 515 
object selection, 514-537 
Reversi, 278-284 
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game state space, 222 

GameState variable, 231-233 

game turn, 492 

GDI (Graphical Device Interface), 44 
colors, 61 
surfaces, 155-158 


GDICanvas.cpp file, 117-118, 120, 156, 
177 


GDICanvash file, 115, 118, 120, 156 
GDI objects 
destroying, 60 
fills, 69-73 
pixel plotting, 60-63 
placing in DC (device context), 
59-60 
regions, 92-102 
GetAnchor function, 390, 393 
GetAnchorSpace function, 390, 392 
GetAnchorSpaceH eight function, 390, 
392-393 
GetAnchorSpaceWidth function, 390, 
392 


GetAsyncKeyState function, 31-32 
GetAttachedSurface function, 153 
GetClientRect function, 52, 55-56 
GetCurrentPositionEx function, 65-66 
GetCursorPos function, 407, 679 
GetDC function, 57-58, 155-158 
GetDisplayM ode function, 144, 185 
GetDOS function, 253 
GetFileN ame function, 253 
GetFrequency function, 202-203 
GetH eight function, 118, 380, 399 
GetH WrapMode function, 390, 394 
GetM apT ype function, 379, 380-381, 
385- 386 
GetM essage function, 24 
GetPan function, 204-205 
GetPixelFormat function, 169 
GetPixel function, 62 
GetPolyFillMode function, 77 
GetReferencePoint function, 399 
GetRegionData function, 182- 183 
GetScreenSpace function, 390-391 
GetScreenSpaceH eight function, 


GetScreenSpaceWidth function, 
390-391 


GetScroller function, 400 
GetStockO bject function, 158 
GetSystemM etrics function, 40 
GetTickCount function, 233 
GetTileCount function, 252 
GetTileH eight function, 380-381 
GetTileList function, 253 
GetTileWalker function, 400 
GetTileWidth member function, 


GetVolume function, 203 
GetVWrapM ode function, 390 


GetVWrapmode function, 394 

GetWidowText function, 39-40 

GetWidth function, 118, 380, 399 

GetWindowlnfo function, 38-39 

GetWindowRect function, 52-53, 
55-56 

GetWindowTextLength function, 
39-40 


GetWorldSpace function, 390-391 
GetWorldSpaceH eight function, 390, 


392 
GetWorldSpaceWidth function, 390, 
392 


GET X LPARAM macro, 34 
GET Y LPARAM macro, 34 
global tilesets, 463 
global variables 
hInstance parameter's value in, 16 
IsoH ех18 3.cpp file, 493, 495-497 
IsoH exCore example, 402-403 
Reversi, 277-278 
TileMap editor, 266 
GPM ega, 286-287 
graphics, 44 
oddly-shaped, 113-115 
parsing into arrays of rectangles and 
points, 245 
grayscaling, 574-575 
GS CLICKCENTER game state, 
-520-524 
GS_CLICKSELECT game sate, 
520-523 
GS CLICKSTACK game state, 520-528 
GS DOMOVE game state, 471-472, 
- 416-478, 494, 502 
GS DONEMOVE game state, 471-472, 
"478-480 
GS ENDMOVE game state, 494, 
502-503 


GS ENDTURN game state, 494, 
499-500 

GS FLIP game state, 275 

GS HOLDPOSITION game state, 
-519-520 

GS_IDLE game state, 471-473, 494, 
~500, 505-507, 514-516, 533-534 

GSL_FLIP game state, 282-283 

GS NEWGAME game state, 275, 280 

GS_NEXTPLAYER game state, 275, 
~ 283-284 

GS NEXTUNIT game state, 498-499, 
513-514, 517-519, 536 

GS NONE game state, 275 

GS NULLMOVE game state, 494, 
- 500-501, 505, 519 

GS PICKUNIT game state, 520-523, 
- 528-531, 533-534 

GS SHIPMOVE game state, 501 

GS SKIPMOVE game state, 494, 506 

GS STARTMOVE game state, 


471-415, 494, 501-502, 507-508, 


519 
GS STARTTURN game state, 494, 497, 
516-517 
GS WAITFORINPUT game state, 275 
GUID (globally unique identifier), 34 


HAL device, 639 
handles 

to brush, 19 

to icon, 18 

to mouse cursor, 19 

ordinary variables, 6 
hardware GUID (globally unique iden- 

tifier), 34 

hatch brush styles, 70 
HBITMAP object, 59 
H BRUSH object, 59 
HDC operator, 118 
head node, 482 
hearing, operation of, 191 
height mapping, 682-685 
HEPNs, 64 
hexagonal, 287 
hexagonal tile-based games, 703-704 
hex maps, 287 
hex tiles, 287-288 

direction of movement, 314 

plotting, 304 

standard, 301 
HFONT object, 59 
HINSTANCE, 6 
hInstMain global variable, 16 
HIWORD macro, 34 
hpenN ew global variable, 66 
HPEN object, 59 
hpenOld global variable, 66 
HRGN handle, 92 
HRGN object, 59 
Hungarian notation, 700-701 
HWND, 6 
HWND_BOTTOM constant, 36 
hwnd member, 8 
HWND_NOTOPMOST constant, 36 
HWND_TOP constant, 36 
HWND_TOPMOST constant, 36 


icons, 18, 229 
IDI APPLICATION system icon, 18 
IDirect3D7 object, 636-337, 663 
IDirect3DDevice7 object, 636, 638-640 
IDirectDraw/ interface, 131, 143 
functions, 175 
global variable pointing, 133 
IDirectDraw7 object, 131, 188 
cooperative level, 135-136 
creation of, 133 
full-screen, 135-136 
windowed, 135-136 


INDEX 


IDirectDrawClipper interface, 131 
IDirectDrawClipper object, 435-436 
IDirectDrawSurface7 interface, 131 
IDirectDrawSurface7 object, 131 
IDirectDrawSurface7 structure and 
empowering user, 176-177 
IDirectSound, 196 
IDirectSoundBuffer, 215-217 
IDirectSound object, 196-197, 218 
idMoveU nit global variable, 464 
iFringe array, 587 
iGameState switch, 279 
iGameState variable, 471 
iH eight data member, 398 
Пр IDirect3DH ALDevice device, 639 
Пр IDirect3DMM X Device device, 369 
ІІ IDirect3DTnLH alDevice device, 
639 
illegal map locations, 507 
images 
grayscaling, 574-575 
loading, 117 
modulation, 575-577 
transparent, 163-166 
iMapH eight data member, 450 
iMapWidth data member, 450 
InflateRect function, 50 
initialization code, user-supplied, 
23-24 


input, handling, 533 

insert function, 489 

insert method, 490 

instances owning window, 23 

interconnecting structures, 579, 593 
eight-direction structures, 599 
four-direction structures, 593-598 

interfaces, 131 

interlocking | soH ex, 298-305 

interlocking rectangular tiles, 298 

IntersectRect function, 45, 48 

InvalidateRect function, 57 

iPiece member, 276 

IsAnchorCoord function, 394 

15030, plotting tiles, 665-670 

ISODIRECTION enumeration, 374 

IsoDirection function, 319 

ISODIRECTION macros, 375 

І5ОН ех, 286-289, 298-305 

І5ОН ex2 3.cpp file, 66-68 

IsoH ех2 4.cpp file, 71 

IsoHex3 1.срр file, 87 

І5ОН ex3 2.cpp file, 90-91 

І5ОН ex3 3.cpp file, 95-97 

IsoH ex3 4.срр file, 107-108 

IsoH ex3 5.bmp file, 113 

І5ОН ех3 5.cpp file, 111 

IsoHex3 6 1.bmp file, 114 

IsoH ex3 6.bmp file, 114 

IsoH ex3 6.cpp file, 114 

IsoH ex3 7.cpp file, 118 


IsoH ex3 8.cpp file, 120-122 
IsoHex5 1.срр file, 145 
IsoHex6 1.bmp file, 156 
IsoHex6 1.срр file, 156 
IsoH ex6 2.cpp file, 162 
IsoH ex6 3A.cpp file, 165 
IsoH ex6 3.cpp file, 163 
IsoH ex6 4.cpp file, 177 
IsoHex7 1.срр file, 183 
IsoHex7 2.cpp file, 188 
IsoHex8 1.срр file, 195 
IsoH ex8 2.cpp file, 215-217 
IsoHex9 1.cpp file, 230-234 
IsoHex10 2.cpp file, 256-258 


IsoH ex10_3.cpp file, 265 
IsoHex10 4.bmp file, 273 
IsoHex12 Lcpp file, 307 

IsoH ex12 2.cpp file, 311 
IsoHex12 3.cpp file, 321 

IsoH ex12 3 file, 322-324 

IsoH ex12 4.cpp file, 251, 334-336 
IsoHex13 Lcpp file, 341 

IsoH ex13 2.cpp file, 350 


IsoH ex13 4.cpp file, 352 
IsoH ex13 5.cpp file, 355 
IsoHex14 1.срр file, 362 
IsoH ex14 2.cpp file, 364 
IsoHex14 3.cpp file, 369 
IsoH ex14 4.cpp file, 370 
IsoHex15 1.срр file, 401-409 


IsoHex16 1.срр file, 414 


IsoH ex16 2.cpp file, 417-419 
IsoH ex16 3.cpp file, 425-433 
IsoHex17 1.срр file, 439-441 
IsoH ех17 2.cpp file, 446-456 
IsoHex18 1.срр file 
event handling, 468-469 
global variables, 463-464 
initialization, 464-465 
main loop, 465-467 
moving objects, 460-462 
rendering function, 468 
scrolling, 462 
IsoH ex18 2.cpp file, 470 
global variables, 471-472 
GS DOMOVE game state, 476-478 
GS DONEMOVE game state, 
478-480 
GS Idle game state, 472-473 
GS STARTMOVE game state, 
473-475 
initialization/ cleanup, 472 
main loop, 472 
IsoH ех18 3.cpp file, 492 
constants, 493, 495-497 
event handling, 505-508 
game states, 494 
global variables, 493, 495-497 
GS DOMOVE game state, 502 
GS ENDMOVE game state, 502-503 


GS ENDTURN game state, 499-500 
GS IDLE game state, 500 
GS NEXTUNIT game state, 
498-499 
GS NULLMOVE game state, 
500-501 
GS SHIPMO VE game state, 501 
GS STARTMO VE game state, 
501-502 
GS STARTTURN game state, 497 
main loop, 497-503 
rendering function, 503-505 
IsoH ex19 1 file, 514-537 
IsoH ех20 1.cpp file, 559-563 
IsoH ex20 2.cpp file, 563 


IsoH ex20 3.cpp file, 571-574 


IsoH ех21 1.срр file, 586-593 
І5ОН ex21 2.cpp file, 594-598 
IsoH ex22 1.срр file, 605-610 
IsoH ex22 2.cpp file, 611-613 
IsoH ех23 1.cpp file, 624-631 
IsoH ex24 1.cpp file, 650-655, 658 
IsoH ex25 1.cpp file, 665 
І5оН ех25 2.cpp file, 668 
IsoH ех25 3.cpp file, 678 
IsoH ex25 4.cpp file, 679-682 
І5ОН ех25 5.cpp file, 683-685 
IsoHexB 1.срр file, 704 
IsoH exCore engine 
files, 372 
IsoH exCore.h file, 401 
IsoH exDefs.h file, 373-375 
150М ouseM ap.cpp file, 395-401 
150М ouseM ap.h file, 395-401 
IsoScroller.cpp file, 387-395 
IsoScroller.h file, 387-395 
IsoTilePlotter.cpp file, 376-383 
IsoTilePlotter.h file, 376-383 
IsoTileWalker.cpp file, 383-387 
IsoTileWalker file, 383-387 
over view, 372 
IsoH exCore example, 401 
event handling, 408-409 
global variables, 402-403 
initialization and cleanup, 403-406 
main loop, 406-408 
IsoH exCore.h file, 372, 401 
IsoH exDefs.h file, 372-375 
IsoHex DiamondPlotTile function, 
378 
IsoHex DiamondTileWalk function, 384 
IsoH ex engine, 291-292 
converting tilemap coordinates into 
world space coordinates, 291 
determining on which tile mouse 
rests, 325 
MouseM ap component, 325-336, 
351, 369-370 
TilePlotter component, 306-309, 
340-342, 361-362 
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TileWalker component, 314-321, 
342-350, 365-369 
IsoHexl 1.срр file, 4, 9-15 
isohex.net Web site, 706 
IsoH ex RectPlotTile function, 378 
IsoH ex RectTileWalk function, 384 
IsoHex SlidePlotTile function, 378 
IsoHex SlideTileWalk function, 384 
IsoH ex StagPlotTile function, 378 
IsoH ex StagTileWalk function, 384 
IsoH ex tilemaps 
navigating, 291 
slide tilemap, 292-293 
staggered tile map, 293-294 
IsoHexTilePlotterFn data member, 
379-380 
ISOHEXTILEPLOTTERFN type, 
377-379 
І5ОН ex tiles, 289-290 
150Нех tilesets, 294-296 
ISOH EXTILEWALKERF function 
pointer, 383-384 
IsoH exTileWalkerFn data member, 
384- 385 
IsoMapT ype data member, 379-380, 
384-385 
ІБОМАРТҮРЕ enumeration, 375 
isometric, 287 
isometric art 
grayscaling, 574-575 
modulation, 575-577 
tile ripping, 563-574 
Ше santing, 556-563 
isometric games, 227-229 
isometric map, 286 
isometric mazes, 611 
isometric plotting equation, 667 
isometric projection, 287 
isometric tiles, 286, 287 
2:1 ratio, 561 
creation, 559-560 
Ше slanting, 558 
“Isometric Views,” 286 
Isometrix Web site, 707 
IsoMouseM ap.cpp file, 372, 395-401 
IsoMouseM ap.h file, 372, 395-401 
IsoRenderer.cpp file, 446 
IsoRenderer.h file, 446 
IsoScroller.cpp file, 372, 387-395 
IsoScroller.h file, 372, 387-395 
IsoTilePlotter.cpp file, 372, 376-383 
IsoTilePlotter.h file, 372, 376-383 
iso tiles, 287-288 
direction of movement, 314 
plotting, 302 
standard, 301 
IsoTileWalker.cpp file, 372, 383-387 
IsoTileWalker.h file, 372 
IsRectEmpty function, 45, 50 
IsScreenCoord function, 394 


IsWorldCoord function, 394 
iteration, 485-488 

iTileH eight data member, 379-380 
iTileM ap array, 266 

iTileNum member, 276 

iTileSelected global variable, 266 
iTileTop global variable, 266 
iTileWidth data member, 379-380 
iUnitFrame global variable, 472 

iU pdateRectCount data member, 450 
iU pdateRectl ndex data member, 450 
iWidth data member, 398 


K 
keyboard 
controls, 229 
key press and release, 30-31 
messages, 29-32 
special characters, 31 
VK_* constants, 30 
keypad controls, 229 


LaMothe, Andre, 706 
LANDPERC constant, 611 
latency, 191 
layered maps 
basics, 412-413 
map scale layering method, 417-419 
scale layering method, 413-416 
tiles, 412 
layering sprites and tiles, 413 
lines, drawing, 66-69 
LineTo function, 66 
linked lists 
adding to, 484 
checking for empty, 485 
counting nodes, 487 
deleting from, 485 
head node, 482 
iterating through, 485-488 
nodes, 482 
operation of, 482 
searching out particular node, 487 
STL list template, 488-491 
tail node, 481 
user-created, 483 
LoadCursor function, 19 
Load function, 214-215, 251-252, 398 
Loadlcon function, 18 
Loadl mage function, 103 
loading 
bitmap from disk, 103-105 
example programs, 696- 700 
images, 117 
pixel data, 674-675 
Load IsoH ex10 1.bmp file, 243 
localization, 85 
Lock function, 167-173, 205-207, 
672-674 


locking 

sound buffers, 205-207 

surface memory, 167-173 
log function and infinite feedback, 204 
logical units, 85 
lookup table 

construction, 539-540 

fringes, 584-585 

member functions, 398-399 
LOWORD macro, 34 
lowvalue variable, 630 
LPD3D Create function, 662-663 
LPD3DDEV Clear function, 662-664 
LPD3DDEV Create function, 662-663 
LPD3DDEV DrawTriangleL ist func- 

tion, 662, 664 
LPD3DDEV DrawTriangleStrip func- 
tion, 664, 667 

Ipd3ddev global variable, 651 
LPD3DDEV Release function, 662, 


664 
LPD3DDEV SetViewport function, 662 
Ipd3d global variable, 651 
LPD3D Release function, 662-663 
IpddBackBuffer data member, 450 
LPDD Create function, 175 
LPDD Release function, 175 
IpddsBack back buffer, 528 
IpddsBall surface, 162 
LPDDS CreateOffscreen function, 175 
LPDDS CreatePimary structure, 175 
LPDDS CreatePrimary3D function, 
662, 664 
LPDDS CreateTexture function, 662, 
665 


LPDDS CreateTexturePixelFormat 
function, 662, 665, 672 
IpddsFrameBuffer data member, 450 
LPDDS GetSecondary3D function, 
662, 664 
LPDDS GetSecondary function, 175 
LPDDS LoadFromFile function, 176 
IpddsMTiniMap global variable, 545 
LPDDS Release function, 176 
LPDDS ReloadFromFile function, 
176-177 
LPDDS-SetSrcColorKey function, 176 
LPDIRECT3D7 variable, 636 
LPDIRECTDRAWSU RFACE7 struc- 
ture, 153 
functions, 175-176 
LPDSB LoadFromFile function, 218 
LPDSB Release function, 218 
IPitch member, 168-169 
IpSurface member, 168 


MakeM aze function, 605-606 
map coordinates, moving between, 292 
MAPHEIGHT constant, 611 


INDEX 


map location empty, 521 


MapLocation structure, 464, 496, 587, 
595 


MapM ouse function, 400 
map panel, 265 
MapPath array, 627-628, 630 
mapping functions and mouse, 400 
mapping modes, 85 
map scale layering method, 417-419 
MAPSEEDS constant, 611 
map type functions, 381 
MAPWIDTH constant, 611 
MasterU nitSelList, 541 
mazes, 603 

adding doors, 607 

blocked conditions, 607-608 

clearing, 606 

creation of, 604-610 

defining, 604 

direction and change in location, 

605 

isometric, 611 

leaving, 608 

placing door, 609 

populating, 610 

selecting room, 607 

usage, 610-611 

variegation, 610 
mc use cursor, 34 
member functions 

anchor, 393 

anchor space, 392-393 


construction/ destruction, 390-391, 
398 


conversion, 393-394 
lookup table, 398-399 
reference point, 399 
screen space, 391 
scroller, 399-400 
tile size, 399 
tilewalker, 400 
validation, 394 
world space, 391-392 
wrap mode, 394 
memory, 58-59 
menus, 23 
message member, 8, 24 
message pump 
checking for messages, 24-25 
processing messages, 25-26 
message queue, 7-9 
messages 
adding to list of events, 29 
checking for, 24-25 
handling, 8-9 
keyboard, 29-32 
managing, 23-24 
mouse, 32-34 
processing, 25-26 
processing window input, 29-32 


sending to oe 172 
viewing in MSDN 
MiniMap global aie 545-546 
minimaps 
blitting onto back buffer, 550 
cleaning up memory and tileset 
used by, 550 
function, 545 
global variables, 545 
initialization, 546-547 
redrawing, 548-549 
updating, 547-548 
mini-maps, 230 
MiniScroller global variable, 545, 549 
MiniTilePlotter global variable, 545, 549 
MM CENTER value, 397 
mmdLookU p data member, 398 
MM NE value, 397 
MM NW value, 397 
MM SE value, 397 
MM SW value, 397 
mmsystem.h file, 193 
MMX device, 639 
modulation, 575-577 
modulus operator (%), 329-330 
mouse 
buttons, 32-34 
canceling button press, 512 
determining which tile it rests on, 
325 


handle to cursor, 19 
handling input, 520-523 
left button, 533-534 
messages, 32-34 
movement, 32 
releasing left button, 534-537 
in selection window, 535 
mouse controls, 229 
MouseM ap component, 291, 404-405, 
420 
diamond tilemap, 294 
IsoH ex engine, 351, 369-370 
rectangular tile map, 421 
side tilemap, 293 
staggered tile maps, 294 
MOUSEMAPDIRECTION enumerated 
type, 397 
MouseM apLoad function, 332-333 
mousemapping, 426-427 
converting screen coordinates to 
world coordinates, 328 
determining coordinates, 329-330 
diamond tilemaps, 369-370 
Direct3D, 385-387 
example, 334-336 
functions, 400 
lookup table, 331-334 
performing coarse tile walk, 
330-331 
slide tilemaps, 325-336 


staggered tilemaps, 352-352 
subtracting world coordinates from 
upper left of map position, 328 

MoveAnchor function, 390, 393 
MoveCursor function, 323-324 
MoveLeft global variable, 257 
movement points, 513, 516-517 
MoveRight global variable, 257 
MoveToEx function, 65 
MoveWindow function, 37-38, 55-56 
moving 

information between device con- 

texts, 105-109 

objects, 460-480 

windows, 37-38 
MSDN, viewing messages, 34 
MSG structure, 7-8 

messages, 7 
msg variable, 23 
multiple objects, 480-491 
multiple units, 492-508 
multitasking, 4 
multithreaded, 4 


N 


new operator, 142, 481 
піпдех values, 41 
nodes, 482 

nonclient area, 51 


О 
О bjectBitM ask structure, 540 
objects, 240 
COP (coarse object placement), 
459, 460 
DirectX, 130 
FOP (fine object placement), 459 
moving, 460-480 
multiple, 480-491 
on-screen selectable, 540 
placement, 459-460 
object selection 
centering on current unit, 514 
click-selecting units, 512 
design, 511-514 
fog of war, 553 
fortification/ holding position, 
512-513 
game states, 514-537 
handling input, 533 
implementation, 514-537 
minimaps, 543-551 
pixel-perfect, 537-543 
RenderFunc function, 531-533 
scouting, 514 
zones of control, 551-553 
oddly-shaped graphics, 113-115 
odd ytilewalking, 347-350 
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off-screen surfaces, 147, 154-155 
video cards, 151 
windowed Direct Draw, 186 
OffsetRect function, 45, 48 
opening files, 209-210 
operating systems 
event-driven, 7-8 
multitasking, multithreaded, 4 
Options dialog box, 126-128 
OR bitwise operator, 109-110 
overloaded operator (*), 491, 504 
overloaded operator (+), 491 


T 
Paganini.ttf file, 87 
PaintRgn function, 101 
PAINTSTRUCT struct, 27-28 
panning, 204-205 
parent windows, 23 
Pathfinding algorithm 
cells adjacent to cells with known 
distances, 622-623 
known distance value, 623 
usage, 631-632 
patterns and fills, 19 
pCurrent node, 484 
PeekM essage function, 24-25 
pens 
creation of, 64 
drawing line, 66-69 
usage, 64 
pixel formats, 158-166, 169-171 
functions, 175 
known and stable, 171 


pixel-perfect object selection, 537-538 
lookup table construction, 539-540 


unit selection list, 540-543 
pixel plotting example, 62-63 
pixels, 60 

color plotted, 61 

loading data, 674-675 

manipulation functions, 61-62 

plotting to HDC, 61-62 

RGB representation, 61 
pixel-scale movement, 470 
player turn, 492-493 
Play function, 207-208 
playing sounds, 207-208 
PlaySound function, 193-196 
PlotTile member function, 380-381 
plotting 

functions, 381 

hex tiles, 304 

iso tiles, 302 

rectangular tiles, 299 

tiles, 570 
pMouseM ap data member, 450 
POINT structure, 44-50 
polygon fill modes, 77 
Polygon function, 76-77 


polygon region, 93, 100 
pop_back function, 490 
pop front function, 490 
PostM essage function, 29 
PostQ uitM essage function, 26-27 
precalculating extents, 248 
PressEnter.bmp file, 516 
primary surfaces, 147 
coordinates, 186 
creation of, 151-152, 664 
description, 152 
number of back buffers, 152 
safe relase, 152 
video cards, 151 
primitives, 644-649 
processing messages, 25-26 
Prog Done function, 26, 67, 87, 107, 
256, 266, 406 
Prog Init function, 23, 35, 55, 66-67, 
87, 107, 111, 188, 254, 266, 
403-406, 464-465, 651-654 
Prog Loop function, 26, 35, 119, 157, 
231-233, 255-256, 313-314, 406, 
465-467, 668-669, 679 
programs and threads, 4 
Project, Add To Project, Files com- 
mand, 699 
Project, Settings command, 128 
Project Settings dialog, 129-130 
Project Settings (Alt+F7) key combina- 
tion, 129 
pScroller data member, 398, 450 
ptCellSize global variable, 525-526 
ptCellSize variable, 529 
ptCurrent variable, 430-431 
ptCursor variable, 113, 322 
ptEnd variable, 625 
pTilePlotter data member, 450 
pTileWalker data member, 398, 450 
PtinRect function, 45, 50, 325 
ptLastPosition variable, 163 
ptMap variable, 406 
pt member, 8 
ptM ouseM apSize member, 332 
ptMouse variable, 269 
ptPrimeBIt variable, 188 
ptRef data member, 398 
ptRowEnd variable, 430 
ptRowStart variable, 430-431 
de cd data member, 
389- 
ptScreenAnchorScroll variable, 334 
ptShieldO ffset variable, 529-530 
ptStart variable, 590, 625-626 
ptUnit global variable, 464 
ptU nitO ffset global variable, 472, 
525-526, 529 
ptUnitOld global variable, 464 
PUNITINFO typedef, 496 
push_back function, 489 


push front function, 489 
PutTile function, 253 


Querylnterface function, 636-637 


R 
raster operations, 106-109 

bitmasking, 113-115 

example, 111-113 
rcAnchorSpace data member, 389-390 
rcExtent data member, 450 
rcExtent variable, 453 
rcScreenSpace data member, 389-390 
rcSelectWindow global variable, 525 
rcU pdate global variable, 120 
rcWorldSpace data member, 389-390 
ReadFile function, 211-212 
Rectangle function, 74-75 
rectangles, 74-75 
rectangular area, 44-45, 158 
rectangular engine, 291-292 
rectangular region, 94 
rectangular tilemaps, 290-291, 421 
rectangular tiles, 241-242 

blitting, 300 

blitting order, 290 

interlocking, 298 

versus I soH ex tiles, 289-290 

plotting, 299 

tile walking, 315 
rectifying tiles, 570-571 
RECT structure, 44-45 

assigning values, 46 

assignment functions, 46-47 

checking if point is within, 50 

copying, 46-47 

empty, 50 

equal-sized, 50 

functions, 45-50 

intersecting, 48 

joining, 49 

offsetting, 48 

operation function, 47-49 

setting to empty, 47 

testing functions, 50 
RedrawM iniMap function, 545-549 
reducing blits example, 425 

preparatory stage, 426-428 

rendering loop, 428-433 
reference counting, 131 
reference point member functions, 

399 


regions 
clipping, 95-101 
creation of, 92-95 
deleting, 95 
encompass entire clienting area, 99 
HRGN handle, 92 


outlining, 101-102 
usage, 95-102 
RegisterClassEx function, 19 
registering window class, 19 
Reiferson, Matt, 286 
Release configuration, 130 
ReleaseDC function, 57-58, 156-158 
Release function, 131, 636 
releasing DirectX objects, 145 
Reload function, 252 
RemoveF ontResource function, 83 
remove method, 490 
RENDERFN function, 449-450 
RenderFunc function, 456, 468, 472, 
503-505, 588-589, 595-596 
RenderFunction data member, 450 
rendering class, 445-457 
rendering tilemaps, 262 
RenderRow function, 430-431 
render states, 675-676 
RenderTile function, 431 
RenderU pdate function, 122 
RenterTile function, 355 
repainting 
client area, 51 
windows, 27-28 
repeating texture, 564-568 
RestoreAllSurfaces function, 177 
Reversi 
Al_GREEDY level, 274 
АІ HUMAN level, 274 
Al level control, 276 
Al_MISER level, 274 
Al_RANDOM level, 174 
changing Al levels, 284 
designing, 273-276 
features needed by, 284 
game states, 275, 278-284 
GL_NEWGAME game state, 280 
GL_NEXTPLAYER game state, 
283-284 
GL_NONE game state, 279-280 
global variables, 277-278 
GSL_FLIP game state, 282-283 
GS WAITFORINPUT game state, 
281-282 
implementation, 277-284 
keyboard controls, 284 
rules, 272-273 
score indication, 276 
tile information structure, 275-276 
tilesets, 273 
RGB555 pixel format, 171 
RGB565 pixel format, 171 
RGB device, 639 
RGB macro, 61 
RGNDATAH EADER structure, 181 
RGNDATA structure, 181-182 
rhombuses, 287 
RIF format, 212 


Room Maze array, 605 

rounded rectangle, 75-76 

rounded rectangle clipping region, 99 
rounded rectangular region, 94-95 
RoundRect function, 75-76 
RowCount variable, 424 

RowEnd variable, 424 

RowStart variable, 424-425 

rules, 222 


scale layering method, 413-416 
scouting, 514 
screen 
centering on location clicked, 524 
color depths, 60 
pixels, 60 
screen anchor and world space, 
310-311 
screen coordinates 
converting to client coordinates, 
186-187 
converting to world coordinates, 
328 


screen saver, 156-158 
screen space, 239, 264 
member functions, 391 
slide tilemaps, 309 
screen-to-view anchor, 264 
ScreenToWorld function, 393 
ScreenU nitSelList, 541 
scroller, 404 
scroller member functions, 399-400 
SCROLLERWRAPMODE enumera- 
tion, 389 
ScrollFrame function, 452 
scrolling 
diamond tilemaps, 363-364 
frame buffer, 442 
slide tilemaps, 309-314 
SDK (Software Developer’s Kit), 125 
secondary surfaces, 147 
creation of, 152-154 
reasons for using, 153 
retrieving, 153 
selecting objects. See object selection 
selection window 
cell size, 525-527 
color, 526 
color fill, 528-529 
displaying every frame, 528-531 
initialization, 526-527 
location, 525 
mouse in, 535-536 
pointer to units within, 525-526 
position, 527 
selecting unit from, 525 
showing, 527-528 
size, 525 


SelectO bject function, 59-60, 64, 70, 


85, 95 
SelectU nitList array, 525-529 
SendM essage function, 28-29 
SetAnchor function, 390, 393 
SetAnchorSpace function, 390, 392 
SetBackBuffer function, 451 
SetBkM ode function, 85-86 
SetClipList function, 181 
SetClipper function, 183-184 
SetCooperativel evel function, 
135-136, 197-198 
SetDisplayMode member function, 143 
SeteRectE mpty function, 47 
SetExtentRect function, 451 
SetFrameBuffer function, 451 
SetH Wnd function, 187- 188 
SetH WrapM ode function, 390, 394 
SetM apM ode function, 85 
SetM apSize function, 451-452 
sien S function, 379, 380-381, 


SetM оиѕеМ ар function, 451 
SetPan function, 204 
SetPixel function, 61 
SetPixelV function, 61-62 
SetPlotter function, 451 
SetPolyFillM ode function, 77 
SetRectEmpty function, 45 
SetRect function, 45-46 
SetReferencePoint function, 399 
SetRenderFunction function, 451 
SetRenderState function, 675-676 
SetScreenSpace function, 390- 391 
SetScroller function, 400, 451 
SetTextColor function, 86 
SetTexture function, 658 
SetTileWalker function, 400 
SetU pdateRectCount function, 451 
SetU pMap function, 307-308 
SetupMinMap function, 545-547 
SetU pSpaces function, 311-312, 
352-353, 356-357 

SetViewport function, 641 
SetVolume function, 203 
SetVWrapM ode function, 390 
SetWalker function, 451 
SetWindowPos function, 35-37 
SetWindowText function, 40 
SetWorldSpace function, 390-392 
SetWrapM ode function, 394 
shape function, 73-79 
shapes 

ellipse, 73-74 

filling, 101 

polygons, 76-77 

rectangles, 74-75 

rounded rectangle, 75-76 
ShowBoard function, 279 
ShowlsoCursor function, 322-323 
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GDI, 155-158 

hardcoding pitches, 169 
locking and unlocking, 672-674 
locking memory, 167-173 
off-screen, 147 

pixel formats, 158-166, 170-171 
primary, 147 

reallocating memory, 177 
secondary, 147 

specifying type, 150 

tilesets, 253 


ShowMap function, 573-574 
ShowM apPanel function, 267 
ShowMiniM ap function, 545-547, 550 
ShowPlayers function, 279 
ShowScores function, 279 
ShowTheCursor function, 113 
ShowTilePanel function, 268-269 
sight radius, 553 

single-step tilewalking, 343 

SlideMap TilePlotter function, 307 
SlideMap TileWalker function, 


unlocking, 207 
sound cards, operation of, 193 
source color keys, 164 
source rectangles, 245 
space, 239 
speakers 

operation of, 192-193 

panning, 204-205 
special-case code, 340 
special characters, 31 
SpriteLib, 241 


320- 321, 342-343 

slide tilemaps, 292-293 

anchor space, 311 

calculating world space, 310 

coordinate system, 305-306 

enumeration for direction con- 
stants, 319 

limitations, 309 

mousemapping, 325-336 

northeast moves, 317 

north moves, 317 

screen anchor, 310-311 

screen space, 309 

scrolling, 309-314 

single-step tilewalking, 343 

south move, 318 

southwest moves, 318 

tile plotting, 306-309 

tile walking, 314-321, 343-343 

two-dimensional array, 305 

view space, 309 


sound 


adjusting volume, 218 
attenuation, 203 
controlling, 202-205 
decibels, 203 

digital, 191 
empowering user, 218 
format, 213 
frequency, 202-203 
latency, 191 

length, 202 

operation of ears, 191 
panning, 204-205 
pitch, 202 

playing, 207-208 
properties, 200-202 
turning off, 218 
volume controls, 203-204 
WIN 32, 193-196 


sound buffers 


creation of, 198-200 
DSBCAPS CTRLFREQUEN CY flag, 
202 


duplicating, 208 
locking, 205-207 
new, 218 

raw audio data, 213 
save release, 218 


sprites, 239 
animated example, 254-258 
Direct3D, 670-679 
layering, 413 
loading pixel data, 674-675 
locking and unlocking surfaces, 
672-674 
texture formats, 670-672 
texture surface, 671 
square tiles, 241-242 
SRCPAINT raster operation, 108-109 
StackSize function, 491 
staggered tilemaps, 293-294 
coordinate system, 339-340 
cylindrical, 354-358 
eliminating jaggies, 352-354 
even y tilewalking, 346-347 
map coordinates as two special 
cases, 344-345 
mousemapping, 352-352 
MouseM apping component, 294 
problems tilewalking, 344 
tileplotting, 340-342 
TilePlotting components, 294 
tilewalking, 342-350 
TileWalking component, 294 
unique properties, 352-358 
staggered tilewalking, 347-350 
StagM ap_TilePlotter function, 341 
StagMap TileWalker function, 
349-350 
standard hex tiles, 301 
standard iso tiles, 301 
STD list template, 489-491 
std name space, 488 
STL (Standard Template Library), 488 
STL list template, 488-491 
streaming buffers, 205 
SubtractRect function, 50 
surfaces 
assigning clipper to, 183- 184 
attached, 153 
color fill, 162 
color keys, 163-167 
copying between, 162-163 
creation of, 147-148, 672 
decreasing order of importance, 151 
Direct3Dcreation, 637-638 
direct access to, 169 


unlocking, 173 

usage, 155-167 
Sweet O blivion Web site, 287 
swmH orizontal data member, 389-390 
swmVertical data member, 389-390 
System font table, 83 
System memory and off-screen sur- 

faces, 154-155 

system metrics, 40-41 


Теат nitList, 519 
templates 
extended, 245 
tilesets, 243-248 
temporary swap file, 6 
text 
color, 86 
formatting, 89-91 
outputting to window, 86-89 
TextO ut function, 86-89 
texture, 563-564 
texture.bmp file, 670 
texture mapping example, 658 
textures 
coordinates, 656-658 
definition of, 655-656 
different pixel format, 665 
finding on Web, 565 
formats, 670-672 
getting tiles from, 568-571 
mapping, 656-658 
number of tiles from, 569-570 
repeating from nonrepeating tex- 
ture, 564-568 
rules, 655-656 
surface creation, 672 
surface with given width and height, 
665 
tiling, 569 
TheWidowProc function, 18 
TheWindowProc procedure, 107 
threads, 4 
tile array, 253 
tile-based games 
3D, 238 
agents, 238, 240 
anchors, 240 
anchor space, 240 
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animated sprite example, 254-258 
complicated tilemaps, 261-262 
CTileSet class, 248-253 
extent, 240 
managing tilesets, 243-248 
movement costs, 238 
myths, 238 
objects, 240 
rectangular tiles, 241-242 
Reversi example, 272-284 
rules of, 238 
screen space, 239 
space, 239 
sprites, 239 
square tiles, 241-242 
tilemaps, 240, 259-272 
tiles, 239 
tilesets, 239 
tile space, 239 
view space, 239 
world space, 239 
TILEINFO structure, 248-249 
TileM ap editor, 265 
accepting input, 269-271 
constants, 265-266 
global variables, 266 
main loop, 267-269 
set up and clean up, 266 
tilemaps, 240 
basics, 259-261 
complicated, 261-262 
converting coordinates into world 
space coordinates, 291 
cylindrical, 354-358 
diamond, 360-370 
identifiers, 375 
layers, 261-262 
rectangular versus 150Н ex, 290-291 
rendering, 262 
screen space, 262-265 
size, 263 
torus, 354 
two-dimensional arrays, 259 
view space, 264 
world space, 264 
tile panel, 265 
TilePlotter component, 291, 328, 
404-405 
diamond tilemap, 294 
IsoH ex engine, 306-309, 340-342, 
361-362 


slide tilemap, 293 

tileplotting 
diamond tilemaps, 361-362 
staggered tile maps, 340-342 

tile ripping 
blitting rectangular area to tile, 571 
getting tiles out of texture, 568-571 
looping through tiles, 570 
plotting tiles, 570 


rectifying tiles, 570-571 
repeating texture from nonrepeat- 
ing texture, 564-568 
texture, 563-564 
tiles, 239, 253 
anchor point, 253 
blitting, 247 
blitting rectangular area to, 571 
destination surfaces, 253 
fringes, 581-584 
layered maps, 412 
layering, 413 
looping through, 570 
numbering, 253 
parsing image into, 251-252 
plotting, 570 
rectifying, 570-571 
tile selection panel, 263-264 
tilesets, 239, 262-263, 404-405 
accessing tile information, 253 
animated sprite example, 254-258 
control colors, 245 
file name, 253 
freeing resources used by, 252 
global, 463 
managing, 243-248 
number of tilesin, 252 
reloading image, 252 
Reversi, 273 
surfaces, 253 
templates, 243-248 
tile size functions, 381, 399 
tile slanting 
color-blended, 562-563 
isometric tile creation, 559 
isometric tiles, 558 
tile space, 239 
TileWalker component, 292, 404 
diamond tilemap, 294 
IsoH ex engine, 314-321, 342-350 
slide Шетар, 293 
staggered tile maps, 294 
TileWalkerFunction function, 384 
TileWalker member function, 385-386 
TileWalk function, 385 
tilewalking 
diamond tilemaps, 365-369 
even y, 346-347 
odd y, 347-350 
problem with staggered tile maps, 
344 


rectangular tiles, 315 
single-step, 343 
slide tilemap, 314-321, 343-343 
staggered tilemaps, 342-350 
tile zones, 584-585 
TIMEMAPSQUARE structure, 262 
time member, 8 
time slice, 5 
TnLHal device, 639 


Tools, Options command, 125 

topmost windows, 36 

torus tilemaps, 354 

TranslateM essage function, 25 

transparency, 113 

transparent images, 163-166 

treeshadowts.bmp file, 414 

treetsbmp file, 414 

triangle list, 664 

triangles, 635 

triangle strip, 664 

Tricks for the Windows Game 
Programming Gurus, 707 

Tricks of the Window Game Programming 
Gurus, 706 

tsBack object, 463 

tsCaveM an global variable, 254 

tsCursor tileset, 322 

15150 tileset, 407 

М iniMap global variable, 545, 547, 
549 


tsPressEnter teleset, 514 

tsTileSet global variable, 266 

tsTree object, 463 

tsU nit object, 463 

turn-based strategy games, 228, 492, 511 
typedef, 378 


U 
UnionRect function, 45, 49, 120-121, 
363-364, 453 
UnitInfo structure, 495-496, 513 
UNITLISTITER typedef, 496 
UNITLIST typedef, 496 
units 
centering in cell, 525-526, 529 
centering on current, 514 
checking for, 529 
clicked on, 523 
click-selecting, 512 
current, 522, 531 
empty location, 531 
fortification/ holding position, 
512-513 
holding position, 515-517, 519, 
530-531 


linked lists, 481-482 

movement points, 513, 516-517, 
523, 530 

multiple, 492-508 

none left to move, 517-518 

number of, 522 

only at map location, 532 

player belonging to, 521 

receiving orders, 522 

rendering, 531-532 

selecting from stack, 525-526 

sight radius, 553 

storage methods, 480-491 
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UnitSel, 541 
unit selection list, 540-543 
UnitSelector, 541 
Unload function, 252 
Unlock function, 173, 207, 672-674 
unlocking 
sound buffers, 207 
surfaces, 173 
U pdateFrame function, 452, 456 
U pdateM iniMap function, 545-547 
update rectangle, 119-122 
U pdateRowEnds function, 430-431 
updating 
dipping rectangles, 443-445 
frame buffers, 44 
frames, 528 
minimaps, 547-548 
user-created linked lists, 483 
user-defined callback function, 
137-138 
user interface, 229 
users, empowering, 176-177 


user-supplied initialization code, 23-24 


validation member functions, 394 
Vanier, Isaac, 286 

variables, 258, 377 

vert array, 651 

vertex array, 653 

VERTEX Set function, 662, 665 
VertexX variable, 679 

VertexY variable, 679 

vertices, 647-649, 676-678 

video cards, 151 


video memory and off-screen surfaces, 
155 


video resources, 176-177 

viewports, 663 

view space, 239, 264, 309 

virtual keycode-to-ISO DIRECTION 
mapping, 469 

virtual memory, 6 

VK * constants, 30 

VK SPACE key press, 505 


DU 
WAVEFORMATEX structure, 200-202 
WAV files 
data chunks, 213-214 
fmt chunk, 213 
loading from disk, 213-215 
structure, 212-213 
wcx.IpfnWndProc member, 18 
widows 
DC (device context), 18 
destroying, 27 
WIN 32 


file access, 209-212 
programming, 4 


sounds, 193-196 
WINDING fill mode, 78-79 
window class 

code for setting up, 17-18 

name, 19, 22 

registering, 19 

style, 18 
windowed DirectDraw 

clippers, 187-188 

display modes, 185-186 

lack of back buffers, 186-187 

off-screen surface, 186 
window handles, 6 
WINDOWINFO structure, 38-39 
windowproc, 26-28 
window procedures, 8-9, 18, 26-28 
WindowProc procedure, 9 
windows 

appearance, 22 

area of entire, 52-53 

behavior, 22 

checking existence of, 23 

child, 23 

client area, 51 

creation of, 21-23 

describing type of, 16-19 

elements, 51 

extended styles, 21 

extra creation data, 23 

getting correct size, 55-56 

handle, 6 

information about, 38-39 

instance owning, 23 

length of title, 39-40 

managing, 35-40 

menus, 23 

moving, 37-38 

name of window class, 22 

nonclient area, 51 

outputting text to, 86-89 

parent, 23 

processing input with messages, 

29-32 


repainting, 27-28 
repainting resized, 18 
responding to double-clicks, 18 
sending messages to, 28-29 
size, 35-36 
title, 22, 39-40 
topmost, 36 
z-order, 35-36 
Windows Game Programming for 
Dummies, 707 
Windows platform, 4 
Windows programs over view, 4-6 
WinMain function, 9-26, 15-16, 20-21 
winmm.lib library, 130, 193 
W key press, 506 
WM ACTIVATEAPP message, 34-35, 177 
WM BUTTONDOWN message, 455 


а message, 25, 29, 31 
WM_DESTROY message, 27 

WM_KEYDOWN message, 25, 29-31, 
257, 323, 409 

WM_KEYUP message, 25, 29-31, 257 

WM_LBUTTONDOWN message, 32, 
67, 107, 114, 269-271, 512, 
533-534 

WM_LBUTTONUP message, 32, 279, 
281, 512, 534-537 

WM_MOUSEMOVE message, 32, 63, 
67, 113, 269-271, 335, 358, 
407-409, 455 

WM_MOVE message, 187-188 

WM_NCPAINT message, 51 

WM_PAINT message, 27-28, 51, 
56-57, 113, 120 

WM_QUIT message, 24-25 

WM_RBUTTONDOWN message, 32, 
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WM RBUTTONUP message, 32 
WM SYSCHAR message, 25 
WM SYSKEYDOWN message, 25 
WM SYSKEYU P message, 25 
WNDCLASSEX structure, 16-19 
world building continents, 611-613 
world coordinates, converting screen 
coordinates to, 328 

world generation, 602-603 
worlds 

believability, 602-603 

cohesiveness, 602 

generating, 602-603 

mazes, 603-611 

playability, 603 

replayability, 603 
world space, 239, 264 

coordinates converting to tilemap 

coordinates, 291 

member functions, 391-392 

screen anchor, 310-311 

slide tilemaps, 310 
WorldToScreen function, 394 
wParam flags, 33 
wParam member, 8 
WrapAnchor function, 390, 393 
WRAPMODE CLIP value, 389 
wrap mode member functions, 394 
WRAPMODE_NONE value, 389 
WRAPMODE_WRAP value, 389 
wrapper, purposes, 176 
WriteFile function, 210-211 


x 
XOR bitwise operator, 109, 111, 113 
XTreme Games Web site, 706 


zones of control, 551-553 
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Xtreme Games LLC was founded to help small game developers 
around the world create and publish their games on the commercial 
market. Xtreme Games helps younger developers break into the field 
of game programming by insulating them from complex legal and 
business issues. Xtreme Games has hundreds of developers around 
the world, if you're interested in becoming one of them, then visit us 
at www.xgames3d.com. 
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